Doc: Edit documentation for executor_threads (#435)

Bump to v6.2.2

CHANGELOG.md

@@ -1,5 +1,6 @@
-## Unreleased
+## 6.2.2
  - Fix: update to Gradle 7 [#432](https://github.com/logstash-plugins/logstash-input-beats/pull/432)
+ - [DOC] Edit documentation for `executor_threads` [#435](https://github.com/logstash-plugins/logstash-input-beats/pull/435)
 
 ## 6.2.1
  - Fix: LS failing with `ssl_peer_metadata => true` [#431](https://github.com/logstash-plugins/logstash-input-beats/pull/431)

VERSION

@@ -1 +1 @@
-6.2.1
+6.2.2

docs/index.asciidoc

@@ -232,14 +232,14 @@ Refer to <<plugins-{type}s-{plugin}-ecs_metadata,ECS mapping>> for detailed info
   * Default value is 1 executor thread per CPU core
 
 The number of threads to be used to process incoming beats requests.
-By default Beats input will create a number of threads equals to 2*CPU cores to handle incoming connections,
-reading from the established sockets and execute most of the tasks related to network connection managements, 
-except the parsing of Lumberjack protocol that's offloaded to a dedicated thread pool.
+By default the Beats input creates a number of threads equal to 2*CPU cores.
+These threads handle incoming connections, reading from established sockets, and executing most of the tasks related to network connection management. 
+Parsing the Lumberjack protocol is offloaded to a dedicated thread pool.
 
 Generally you don't need to touch this setting.
 In case you are sending very large events and observing "OutOfDirectMemory" exceptions,
 you may want to reduce this number to half or 1/4 of the CPU cores.
-This will reduce the number of threads decompressing batches of data into direct memory.
+This change reduces the number of threads decompressing batches of data into direct memory.
 However, this will only be a mitigating tweak, as the proper solution may require resizing your Logstash deployment,
 either by increasing number of Logstash nodes or increasing the JVM's Direct Memory.