SwiftMQ manages its own network buffers on both sides of the wire (client and router). The length of the data sent to the network is determined by the underlying SMQP protocol handlers. Only complete requests are sent. Those request can also be bulk request which contains collected single requests. Before a request is sent, it is written to a network buffer. The receiving side receives the data into a network buffer as well. Theses buffers are adjusted automatically. However, adjustment may take time when transfering large messages, so it might be necessary to configure buffer/extend sizes that meets the requirements more specific.
Network buffers are initially created with their initial size which is 128 KB by default. If the protocol handler detects that the buffer is full before it can flush it, it will extend the buffer and continues writing until the request is finished or the buffer fills up again which then leads to another extend. The default extend size is 64 KB.
The initial buffer size and the extend size can be specified for:
The input/output sizes for the router is specified in the JMS listener definition. The input/output sizes for the client is specified in the connection factory definition. So it's possible to adjust network buffers for both sides by creating the appropriate JMS listeners and connection factories.
All network buffers are bound to a connection so each connection has one input and one output buffer. If there is a high number of concurrent connections, the overal memory consumption for the network buffers will go up.
Starting with SwiftMQ 7.5.0 the network output buffers (router output, client output) are bound via a ThreadLocal to the thread which writes to the output stream. On the router side these are threads from pool "jms.connection" and on the client side it is the connection threadpool (see below, "Client-Side Threadpools"). The number of network output buffers is therefore the number of threads in the resp. threadpool vs number of connections in releases prior 7.5.0. So there is a dramatic decrease of buffer space since 7.5.0.
Since release 7.3.2 it is possible to specify a particular SMQP protocol version to connect to a SwiftMQ Router. This is only necessary if it is required to connect with a higher versioned JMS client (e.g. CLI) to an older SwiftMQ Router, e.g. if the SwiftMQ Router can't be upgraded due to internal reasons. To use most recent client-side features, the SMQP protocol version can be set with the following system property:
-Dswiftmq.smqp.version=<version>
where "version" is one of the following:
Version 750 is the latest version and default. The protocol version changes if there is a protocol change. For example, version 510 did change with SwiftMQ release 5.1.0. All further releases until 6.0.0 are using version 510 but also contain lower versioned protocol stacks. For example, a SwiftMQ Router 5.2.5's default version is 510 but can also serve versions 500 and 400. A SwiftMQ Router 7.3.2's default version is 630 but can also serve versions 610, 600, 510, 500 and 400.
A JMS client utilizes 2 thread pools, one to drive sessions, and one to drive connection outbound writes (client to router). Both pools are similar to the pools used from the Threadpool Swiftlet (they have the same attributes), however, the pool configuration takes place by system properties, to be defined on the client's command line. The default settings are optimal, so a change would be seldom.
| System Property | Default | Meaning |
|---|---|---|
| swiftmq.pool.session.threads.min | 5 | Minimum threads. This number is prestarted. |
| swiftmq.pool.session.threads.max | 50 | Maximum threads. Default changed to 50 starting from release 7.6.0. |
| swiftmq.pool.session.priority | Thread.NORM_PRIORITY | Thread Priority. |
| swiftmq.pool.session.queue.length | 1 | Pool length (back log), after which an additional thread is started. |
| swiftmq.pool.session.threads.add | 1 | The number of additional threads to start if the queue length is reached. |
| swiftmq.pool.session.idle.timeout | 120000 | Idle timeout after which an additional thread will die. |
| System Property | Default | Meaning |
|---|---|---|
| swiftmq.pool.connection.threads.min | 5 | Minimum threads. This number is prestarted. |
| swiftmq.pool.connection.threads.max | 50 | Maximum threads. Default changed to 50 starting from release 7.6.0. |
| swiftmq.pool.connection.priority | Thread.NORM_PRIORITY | Thread Priority. |
| swiftmq.pool.connection.queue.length | 1 | Pool length (back log), after which an additional thread is started. |
| swiftmq.pool.connection.threads.add | 1 | The number of additional threads to start if the queue length is reached. |
| swiftmq.pool.connection.idle.timeout | 120000 | Idle timeout after which an additional thread will die. |