This closes #870
This commit is contained in:
commit
51fa840617
|
@ -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.
|
||||
|
|
|
@ -132,16 +132,6 @@ tuning:
|
|||
consumer-window-size. This effectively disables consumer flow
|
||||
control.
|
||||
|
||||
- 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](configuring-transports.md). 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
|
||||
|
|
|
@ -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
|
||||
uniquely.
|
||||
|
||||
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
|
||||
|
|
Loading…
Reference in New Issue