The receiver component is responsible for receiving cluster messages.
As you might notice through the configuration, is that the receiving of messages
and sending of messages are two different components, this is different from many other
frameworks, but there is a good reason for it, to decouple the logic for how messages are sent from
how messages are received.
The receiver is very much like the Tomcat Connector, its the base of the thread pool for incoming cluster messages. The receiver is straight forward, but all the socket settings for incoming traffic are managed here.
The receiver supports both a non blocking,
org.apache.catalina.tribes.transport.nio.NioReceiver, and a
org.apache.catalina.tribes.transport.bio.BioReceiver. It is preferred to use the non blocking receiver
to be able to grow your cluster without running into thread starvation.
Using the non blocking receiver allows you to with a very limited thread count to serve a large number of messages. Usually the rule is to use 1 thread per node in the cluster for small clusters, and then depending on your message frequency and your hardware, you'll find an optimal number of threads peak out at a certain number.
org.apache.catalina.tribes.transport.nio.NioReceiveris the preferred implementation
autoand translates to
false. Set to true if you want the receiver to use direct bytebuffers when reading data from the sockets.
4000. To avoid port conflicts the receiver will automatically bind to a free port within the range of
port <= bindPort < port+autoBindSo for example, if port is 4000, and autoBind is set to 10, then the receiver will open up a server socket on the first available port in the range 4000-4009.
100. Use this value if you wish to automatically avoid port conflicts the cluster receiver will try to open a server socket on the
portattribute port, and then work up
autoBindnumber of times.
NioReceiver. On older versions of the JDK there have been bugs, that should all now be cleared out where the selector never woke up. The default value is a very high
15Adjust this value relative to the number of nodes in the cluster, the number of messages being exchanged and the hardware you are running on. A higher value doesn't mean more efficiency, tune this value according to your own test results.
false. Default value is
false. The default value is
org.apache.catalina.tribes.io.XByteBufferobjects. If set to true, the XByteBuffer that is used to pass a message up the channel, will be recycled at the end of the requests. This means that interceptors in the channel must not maintain a reference to the object after the
org.apache.catalina.tribes.ChannelInterceptor#messageReceivedmethod has exited.