The Apache Tomcat Servlet/JSP Container

Apache Tomcat 7

Version 7.0.57, Nov 3 2014
Apache Logo

Links

Top Level Elements

Executors

Connectors

Containers

Nested Components

Cluster Elements

web.xml

Other

The Cluster Sender object

Table of Contents
Introduction

The channel sender component is responsible for delivering outgoing cluster messages over the network. In the default implementation, org.apache.catalina.tribes.transport.ReplicationTransmitter, the sender is a fairly empty shell with not much logic around a fairly complex <Transport> component the implements the actual delivery mechanism.

Concurrent Parallel Delivery

In the default transport implementation, org.apache.catalina.tribes.transport.nio.PooledParallelSender, Apache Tribes implements what we like to call "Concurrent Parallel Delivery". This means that we can send a message to more than one destination at the same time(parallel), and deliver two messages to the same destination at the same time(concurrent). Combine these two and we have "Concurrent Parallel Delivery".

When is this useful? The simplest example we can think of is when part of your code is sending a 10MB message, like a war file being deployed, and you need to push through a small 10KB message, say a session being replicated, you don't have to wait for the 10MB message to finish, as a separate thread will push in the small message transmission at the same time. Currently there is no interrupt, pause or priority mechanism available, but check back soon.

Nested Elements

The nested element <Transport> is is not required, by encouraged, as this is where you would set all the socket options for the outgoing messages. Please see its attributes below. There are two implementations, in a similar manner to the receiver, one is non-blocking based and the other is built using blocking IO.
org.apache.catalina.tribes.transport.bio.PooledMultiSender is the blocking implementation and org.apache.catalina.tribes.transport.nio.PooledParallelSender. Parallel delivery is not available for the blocking implementation due to the fact that it is blocking a thread on sending data.

Attributes
Common Sender Attributes
AttributeDescription
className Required, only available implementation is org.apache.catalina.tribes.transport.ReplicationTransmitter
Common Transport Attributes
AttributeDescription
className Required, an implementation of the org.apache.catalina.tribes.transport.MultiPointSender.
Non-blocking implementation is org.apache.catalina.tribes.transport.nio.PooledParallelSender
Blocking implementation is org.apache.catalina.tribes.transport.bio.PooledMultiSender
rxBufSize The receive buffer size on the socket. Default value is 25188 bytes.
txBufSize The send buffer size on the socket. Default value is 43800 bytes.
udpRxBufSize The receive buffer size on the datagram socket. Default value is 25188 bytes.
udpTxBufSize The send buffer size on the datagram socket. Default value is 43800 bytes.
directBuffer Possible values are true or false. Set to true if you want the receiver to use direct bytebuffers when writing data to the sockets. Default value is false
keepAliveCount The number of requests that can go through the socket before the socket is closed, and reopened for the next request. The default value is -1, which is unlimited.
keepAliveTime The number of milliseconds a connection is kept open after its been opened. The default value is -1, which is unlimited.
timeout Sets the SO_TIMEOUT option on the socket. The value is in milliseconds and the default value is 3000 milliseconds.(3 seconds) This timeout starts when a message send attempt is starting, until the transfer has been completed. For the NIO sockets, this will mean, that the caller can guarantee that we will not attempt sending the message longer than this timeout value. For the blocking IO implementation, this translated directly to the soTimeout.
A timeout will not spawn a retry attempt, in order to guarantee the return of the application thread.
maxRetryAttempts How many times do we retry a failed message, that received a IOException at the socket level. The default value is 1, meaning we will retry a message that has failed once. In other words, we will attempt a message send no more than twice. One is the original send, and one is the maxRetryAttempts.
ooBInline Boolean value for the socket OOBINLINE option. Possible values are true or false.
soKeepAlive Boolean value for the socket SO_KEEPALIVE option. Possible values are true or false.
soLingerOn Boolean value to determine whether to use the SO_LINGER socket option. Possible values are true or false. Default value is true.
soLingerTime Sets the SO_LINGER socket option time value. The value is in seconds. The default value is 3 seconds.
soReuseAddress Boolean value for the socket SO_REUSEADDR option. Possible values are true or false.
soTrafficClass Sets the traffic class level for the socket, the value is between 0 and 255. Default value is int soTrafficClass = 0x04 | 0x08 | 0x010; Different values are defined in java.net.Socket#setTrafficClass(int).
tcpNoDelay Boolean value for the socket TCP_NODELAY option. Possible values are true or false. The default value is true
throwOnFailedAck Boolean value, default value is true. If set to true, the sender will throw a org.apache.catalina.tribes.RemoteProcessException when we receive a negative ack from the remote member. Set to false, and Tribes will treat a positive ack the same way as a negative ack, that the message was received.
Common PooledSender Attributes
AttributeDescription
poolSize The maximum number of concurrent connections from A to B. The value is based on a per-destination count. The default value is 25
maxWait The maximum number of milliseconds that the senderPool will wait when there are no available senders. The default value is 3000 milliseconds.(3 seconds).
Comments

Notice: This comments section collects your suggestions on improving documentation for Apache Tomcat.

If you have trouble and need help, read Find Help page and ask your question on the tomcat-users mailing list. Do not ask such questions here. This is not a Q&A section.

The Apache Comments System is explained here. Comments may be removed by our moderators if they are either implemented or considered invalid/off-topic.


Copyright © 1999-2014, Apache Software Foundation