14.4. Configuring the Netty transport
HornetQ uses Netty, a high-performance, low-level network library.
The Netty transport can be configured to use old (blocking) Java IO, NIO (non-blocking), TCP sockets, SSL, HTTP or HTTPS. A servlet transport is also provided.
14.4.1. Configuring Netty TCP
Netty TCP is a simple unencrypted TCP socket-based transport. Netty TCP can be configured to use blocking Java Asynchronous IO (AIO) or non-blocking Java NIO (NIO). NIO is recommended on the server-side for concurrent connection scalability; however, AIO can provide better latency if many concurrent connections are not required.
Warning
If you are running connections across an untrusted network, consider SSL or HTTPS instead.
Important
If non-blocking messages are sent then there is a chance that these could arrive on the server after the calling thread has completed. This means that the security context has been cleared. If this is the case then messages will need to be sent as blocking messages.
With the Netty TCP transport all connections are initiated from the client side. This is useful in situations where firewall policies only allow connections to be initiated in one direction.
All valid Netty transport keys are defined in
org.hornetq.core.remoting.impl.netty.TransportConstants. Most parameters can be used with acceptors and connectors. Some only work with acceptors. The following parameters can be used to configure Netty for simple TCP:
-
use-nio - If this is
truethen Java non-blocking NIO will be used. If set tofalsethe older, blocking Java IO will be used. If handling many concurrent connections to the server is a requirement, the non-blocking Java NIO method is highly recommended. Java NIO does not maintain a thread per connection so can scale to many more concurrent connections than the older blocking IO method. If handling many concurrent connections is not required, slightly better performance might be gained by using older blocking IO method. The default value for this property isfalseon the server side andfalseon the client side. -
host - The host name or IP address to connect to (for connectors) or listen on (for acceptors). The default value is
localhost.Important
The default for this variable islocalhost. This is not accessible from remote nodes and must be modified for the server to accept incoming connections.Acceptors can be configured with multiple comma-delimited hosts or IP addresses. Multiple addresses are not valid for connectors.0.0.0.0specifies that all network interfaces of a host should be accepted. -
port - Specifies the port to connect to (for connectors) or listen on (for acceptors). The default value is
5445. -
tcp-no-delay - If
true, Nagle's algorithm is enabled. The default value istrue. -
tcp-send-buffer-size - Defines the size of the TCP send buffer in bytes. The default value is
32768(32 kilobytes). TCP buffer size should be tuned according to the bandwidth and latency of your network. The buffer size in bytes should be equal to the bandwidth in bytes-per-second multiplied by the network round-trip-time (RTT) in seconds. RTT can be measured using the ping utility. For fast networks, you may wish to increase the buffer size from the default value. -
tcp-receive-buffer-size - Defines the size of the TCP receive buffer in bytes. The default value is
32768(32 kilobytes). -
batch-delay - HornetQ can be configured to place write operations into batches for up to
batch-delaymilliseconds. This can increase overall throughput for very small messages, but does so at the expense of an increase in average latency for message transfer. The default value is0milliseconds. -
direct-deliver - When a message arrives on the server and is delivered to consumers, by default the delivery occurs on a different thread to that in which the message arrived. This gives the best overall throughput and scalability, especially on multi-core machines. However, it also introduces additional latency due to the context switch required. For the lowest latency (and possible reduction of throughput), set
direct-delivertotrue(the default). For highest throughput, set tofalse. -
nio-remoting-threads - When configured to use NIO, by default HornetQ uses three times the number of threads as cores (or hyper-threads) reported by
Runtime.getRuntime().availableProcessors()to process incoming packets.nio-remoting-threadsoverrides this and defines the number of threads to use. The default is-1, which represents three times the value fromRuntime.getRuntime().availableProcessors().
