This topic has not yet been written. The content below is from the topic description.
16.4.1. Configuring Netty TCP Netty TCP is a simple unencrypted TCP sockets based transport. Netty TCP can be configured to use old blocking Java IO or non blocking Java NIO. We recommend you use the Java NIO on the server side for better scalability with many concurrent connections. However using Java old IO can sometimes give you better latency than NIO when you're not so worried about supporting many thousands of concurrent connections. If you're running connections across an untrusted network please bear in mind this transport is unencrypted. You may want to look at the SSL or HTTPS configurations. With the Netty TCP transport all connections are initiated from the client side. I.e. the server does not initiate any connections to the client. This works well with firewall policies that typically only allow connections to be initiated in one direction. All the valid Netty transport keys are defined in the class org.hornetq.core.remoting.impl.netty.TransportConstants. Most parameters can be used either with acceptors or connectors, some only work with acceptors. The following parameters can be used to configure Netty for simple TCP: use-nio. If this is true then Java non blocking NIO will be used. If set to false then old blocking Java IO will be used. If you require the server to handle many concurrent connections, we highly recommend that you use non blocking Java NIO. Java NIO does not maintain a thread per connection so can scale to many more concurrent connections than with old blocking IO. If you don't require the server to handle many concurrent connections, you might get slightly better performance by using old (blocking) IO. The default value for this property is false on the server side and false on the client side. host. This specifies the host name or IP address to connect to (when configuring a connector) or to listen on (when configuring an acceptor). The default value for this property is localhost. When configuring acceptors, multiple hosts or IP addresses can be specified by separating them with commas. It is also possible to specify 0.0.0.0 to accept connection from all the host's network interfaces. It's not valid to specify multiple addresses when specifying the host for a connector; a connector makes a connection to one specific address. Note Don't forget to specify a host name or ip address! If you want your server able to accept connections from other nodes you must specify a hostname or ip address at which the acceptor will bind and listen for incoming connections. The default is localhost which of course is not accessible from remote nodes! port. This specified the port to connect to (when configuring a connector) or to listen on (when configuring an acceptor). The default value for this property is 5445. tcp-no-delay. If this is true then Nagle's algorithm will be enabled. The default value for this property is true. tcp-send-buffer-size. This parameter determines the size of the TCP send buffer in bytes. The default value for this property is 32768 bytes (32KiB). TCP buffer sizes should be tuned according to the bandwidth and latency of your network. Here's a good link that explains the theory behind this. In summary TCP send/receive buffer sizes should be calculated as: buffer_size = bandwidth * RTT. Where bandwidth is in bytes per second and network round trip time (RTT) is in seconds. RTT can be easily measured using the ping utility. For fast networks you may want to increase the buffer sizes from the defaults. tcp-receive-buffer-size. This parameter determines the size of the TCP receive buffer in bytes. The default value for this property is 32768 bytes (32KiB). batch-delay. Before writing packets to the transport, HornetQ can be configured to batch up writes for a maximum of batch-delay milliseconds. This can increase overall throughput for very small messages. It does so at the expense of an increase in average latency for message transfer. The default value for this property is 0 ms. direct-deliver. When a message arrives on the server and is delivered to waiting consumers, by default, the delivery is done on a different thread to that which the message arrived on. This gives the best overall throughput and scalability, especially on multi-core machines. However it also introduces some extra latency due to the extra context switch required. If you want the lowest latency and the possible expense of some reduction in throughput then you can make sure direct-deliver to true. The default value for this parameter is true. If you are willing to take some small extra hit on latency but want the highest throughput set this parameter to false. nio-remoting-threads. When configured to use NIO, HornetQ will, by default, use a number of threads equal to three times the number of cores (or hyper-threads) as reported by Runtime.getRuntime().availableProcessors() for processing incoming packets. If you want to override this value, you can set the number of threads by specifying this parameter. The default value for this parameter is -1 which means use the value from Runtime.getRuntime().availableProcessors() * 3.