activemq-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [2/2] activemq-artemis git commit: NO-JIRA removing OIO references, since Netty is only NIO now
Date Fri, 28 Oct 2016 20:31:54 GMT
NO-JIRA removing OIO references, since Netty is only NIO now


Branch: refs/heads/master
Commit: ebc2bbc672c33bd20130f9a2ca8ff2c98146f49a
Parents: d505f5c
Author: Clebert Suconic <>
Authored: Thu Oct 27 11:30:10 2016 -0400
Committer: Clebert Suconic <>
Committed: Fri Oct 28 16:31:41 2016 -0400

 docs/user-manual/en/ |  1 -
 docs/user-manual/en/            | 10 ----------
 docs/user-manual/en/         | 22 +---------------------
 3 files changed, 1 insertion(+), 32 deletions(-)
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index 5f32d77..37e779d 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -144,7 +144,6 @@ Out of the box, Apache ActiveMQ Artemis currently uses
 network library.
 Our Netty transport can be configured in several different ways; to use
-old (blocking) Java IO, or NIO (non-blocking), also to use
 straightforward TCP sockets, SSL, or to tunnel over HTTP or HTTPS..
 We believe this caters for the vast majority of transport requirements.
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index 653d0be..39f9993 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -132,16 +132,6 @@ tuning:
     consumer-window-size. This effectively disables consumer flow
--   Socket NIO vs Socket Old IO. By default Apache ActiveMQ Artemis uses old (blocking)
-    on the server and the client side (see the chapter on configuring
-    transports for more information [Configuring the Transport](
NIO is much more scalable but
-    can give you some latency hit compared to old blocking IO. If you
-    need to be able to service many thousands of connections on the
-    server, then you should make sure you're using NIO on the server.
-    However, if don't expect many thousands of connections on the server
-    you can keep the server acceptors using old IO, and might get a
-    small performance advantage.
 -   Use the core API not JMS. Using the JMS API you will have slightly
     lower performance than using the core API, since all JMS operations
     need to be translated into core operations before the server can
diff --git a/docs/user-manual/en/ b/docs/user-manual/en/
index 2d3b8d1..1a98203 100644
--- a/docs/user-manual/en/
+++ b/docs/user-manual/en/
@@ -13,27 +13,7 @@ a scheduled thread pool for scheduled use. A Java scheduled thread pool
 cannot be configured to use a standard thread pool, otherwise we could
 use a single thread pool for both scheduled and non scheduled activity.
-A separate thread pool is also used to service connections. Apache ActiveMQ Artemis can
-use "old" (blocking) IO or "new" (non-blocking) IO also called NIO. Both
-of these options use a separate thread pool, but each of them behaves
-Since old IO requires a thread per connection its thread pool is
-unbounded. The thread pool is created via `
-            java.util.concurrent.Executors.newCachedThreadPool(ThreadFactory)`.
-As the JavaDoc for this method states: “Creates a thread pool that
-creates new threads as needed, but will reuse previously constructed
-threads when they are available, and uses the provided ThreadFactory to
-create new threads when needed.” Threads from this pool which are idle
-for more than 60 seconds will time out and be removed. If old IO
-connections were serviced from the standard pool the pool would easily
-get exhausted if too many connections were made, resulting in the server
-"hanging" since it has no remaining threads to do anything else.
-However, even an unbounded thread pool can run into trouble if it
-becomes too large. If you require the server to handle many concurrent
-connections you should use NIO, not old IO.
-When using new IO (NIO), Apache ActiveMQ Artemis will, by default, cap its thread pool
+Apache ActiveMQ Artemis will, by default, cap its thread pool
 at three times the number of cores (or hyper-threads) as reported by `
             Runtime.getRuntime().availableProcessors()` for processing
 incoming packets. To override this value, you can set the number of

View raw message