tomcat configuration session sharing

Reference address:

By looking up information on the Internet, I know that tomcat can actually achieve session sharing. The following describes how to configure and implement session sharing between multiple servers.

1. The easiest way to achieve session sharing between tomcat:

The first step: start a load balancer such as (nginx), which will not be discussed here;

Step 2: Prepare multiple tomcat servers;

Step 3: Modify the server.xml file in the conf directory, remove the comment below, and add <distributable /> before the node </web-app> of the web.xml file ( this is where tomcat performs session replication. It is necessary, otherwise the session cannot be copied!) ;

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/>

Or change the content.xml configuration file of Tomcat, modify <Context distributable="true">, and start the server after configuration.

2. The <Cluster> tag is explained in detail. The default configuration of <Cluster> is as follows

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster" channelSendOptions="8">
			<Manager className="org.apache.catalina.ha.session.DeltaManager" expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/>
			<Channel className="org.apache.catalina.tribes.group.GroupChannel">
				<Membership className="org.apache.catalina.tribes.membership.McastService" address="228.0.0.4" port="45564" frequency="500" dropTime="3000"/>
				<Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver" address="auto" port="4000" autoBind="100" selectorTimeout="5000" maxThreads="6"/>
				<Sender className="org.apache.catalina.tribes.transport.ReplicationTransmitter">
					<Transport className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/>
				</Sender>
				<Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
				<Interceptor className="org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor"/>
			</Channel>
		 
			<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
			<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

			<Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer" tempDir="/tmp/war-temp/" deployDir="/tmp/war-deploy/" watchDir="/tmp/war-listen/" watchEnabled="false"/>
			<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
		</Cluster>

The previously mentioned <Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster"/> simple configuration is equivalent to the default configuration.

    Cluster
    Tomcat cluster configuration. The configuration of the cluster is more complicated, and the default cluster configuration can meet the general development requirements.
    Common attributes:
        className-specify the class used by the Cluster
        channelSendOptions-the way the Cluster sends messages
        channelSendOptions can be set to 2, 4, 8, 10, each number represents a Mode
            2 = Channel.SEND_OPTIONS_USE_ACK (confirm send)
            4 = Channel.SEND_OPTIONS_SYNCHRONIZED_ACK (synchronous send)
            8 = Channel.SEND_OPTIONS_ASYNCHRONOUS (asynchronous send)
        In asynchronous mode, you can increase reliability by adding Acknowledge. channelSendOptions is set to 10

    Manager
        Manager decides how to manage the session information of the cluster. Tomcat provides two kinds of Managers: BackupManager and DeltaManager
        BackupManager-all Sessions under the cluster will be placed on a backup node. All nodes in the cluster can access the backup node
        DeltaManager - Sessions generated or changed by a node in the cluster will be replicated to other nodes. DeltaManager is Tomcat's default cluster manager, which can meet general development needs
        When using DeltaManager, the applications deployed on each node must be the same; when using BackupManager, the applications deployed on each node can have different
        common attributes:
            className - specifies the class that implements the org.apache.catalina.ha.ClusterManager interface
            expireSessionsOnShutdown - when set to true, The shutdown of a node will cause all sessions under the
            cluster to fail notifyListenersOnReplication - whether to notify session listeners of session replication and deletion operations between nodes under the
            cluster maxInactiveInterval - the effective time of the session under the cluster (unit: s). Sessions that are not active within maxInactiveInterval will be recycled by Tomcat. The default value is 1800 (30min)

    Channel
        Channel is a tool for communication between Tomcat nodes. Channel includes 5 components: Membership, Sender, Transport, Receiver, Interceptor

    Membership
        Membership maintains the list of available nodes in the cluster. It can check the newly added nodes, and also check the
        common attributes of nodes without heartbeat:
            className-specify the class used by Membership address-
            multicast address
            port - multicast port
            frequency - time interval (unit: ms) for sending heartbeats (sending UDP packets to multicast addresses). The default value is 500
            dropTime-Membership does not receive a heartbeat from a node within dropTime (unit: ms), and the node is removed from the list of available nodes. The default value is 3000
            Multicast (Multicast): a one-to-many network connection between a sender and multiple receivers. A sender transmits the same data to multiple receivers at the same time, and only needs to make a copy of the same data packet. It improves the efficiency of data transmission and reduces the possibility of congestion in the backbone network
            . Tomcat nodes with the same multicast address and port can form a sub-cluster

    Receiver receiver under the cluster         . There are two types of receivers
        responsible for receiving messages : BioReceiver (blocking
Type), NioReceiver (non-blocking)
        common attributes:
            className - specify the class used by the Receiver
            address - the address to receive the message port -
            the port to receive the message
            autoBind - the change range of the
            port If port is 4000 and autoBind is 100, the receiver will be in the Take a port between 4000 and 4099 to monitor
            selectorTimeout-the timeout time of polling in NioReceiver
            maxThreads - the maximum number of threads in the thread pool

    Sender
        sender, responsible for sending messages
        Sender has a built-in Transport component, and Transport is really responsible for sending messages.
        Transport is divided into two types: bio.PooledMultiSender (blocking), nio.PooledParallelSender (non-blocking)

    Interceptor
        Cluster's interceptor
        TcpFailureDetector - When the network and system are busy, Membership may not be able to update the list of available nodes in time. At this time, TcpFailureDetector can intercept the information that a node is closed, and try to connect to this node through TCP to ensure that the node is really closed , so as to update the cluster, you can use the node list
        MessageDispatch15Interceptor-MessageDispatch15Interceptor to check whether the way the Cluster component sends messages is set to Channel.SEND_OPTIONS_ASYNCHRONOUS (when the channelSendOptions under the Cluster label is 8). When set to Channel.SEND_OPTIONS_ASYNCHRONOUS, MessageDispatch15Interceptor first queues the messages waiting to be sent, and then forwards the queued messages to the Sender

    Valve
        Valve can be understood as Tomcat's interceptor
        ReplicationValve - log before and after processing requests; filtering does not involve Session changes request
        JvmRouteBinderValve - When an error occurs in mod_jk of Apache, it ensures that the request from the same client is sent to the same node in the cluster. The

    Deployer
        synchronizes the consistency of all nodes in the cluster. Deployer has not been tested successfully. . .

    ClusterListener
        listener, listening for messages received by the Cluster component
        When using DeltaManager, the information received by the Cluster is passed to the DeltaManager through the ClusterSessionListener

3. A cluster configured in this way will synchronize the Session to all instances on the network segment where the cluster attributes are configured (the network segment may be inaccurate, because the 228.0.0.4 address is used for broadcasting, I do not Know what kind of broadcast address this is) . That is to say, if all Tomcat instances under the broadcast address will share the session, then if there are several unrelated clusters, it may cause waste of session replication, so in order to avoid waste, it is necessary to set more nodes, as follows:

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">    
    <Channel className="org.apache.catalina.tribes.group.GroupChannel">    
        <Membership className="org.apache.catalina.tribes.membership.McastService"    
            address="228.0.0.4"    
            port="45564"    
            frequency="500"    
            dropTime="3000"/>    
    Channel>    
Cluster>

The cluster deployment and modification actions of tomcat are relatively simple, but there will be a series of problems in the actual operation process. Here I list some problems and main points that occurred in the process of using after configuration, for your reference:
1. Users are stored in SESSION The problem of the data in the
tomcat cluster is used for SESSION replication. You must ensure that all objects stored in your session implement the java.io.Serializable interface, because session replication is to serialize objects to other WEB application servers. So if this interface is not implemented, the SESSION synchronization will fail. Another point is that if there are many machines to be synchronized, you should pay attention to ensure that the data stored in SESSION is relatively small, and do not store everything in SESSION, because copying SESSION also requires overhead, and the larger the data, the greater the overhead.

    2. The trigger condition for Tomcat to perform SESSION replication
        We can see the attribute in the cluster tag of the cluster section in the server.xml file of tomcat: useDirtyFlag, if this is set to true (default), then only when setAttribute is used to set data in the session The SESSION of other WEB servers will be synchronized only when it is false, then the sesison of each request will be synchronized to other servers. Therefore, special attention should be paid when operating SESSION to avoid the problem that SESSION cannot be synchronized.
        For a simple example, for example, we modify a certain data of the user in SESSION in the case of a stand-alone application, then it is usually:

User user = (User)request.getSession().getAttribute("user");
User.setName("my name");

In this way, we directly access it and then modify it. Although there is no problem in the case of a single machine, in the case of a cluster, this leads to the problem of asynchronous synchronization of the SESSION on multiple WEB servers. Because the SESSION has not changed, Tomcat cannot Monitor whether the value of a data in the session has changed. Therefore, we also need to perform the following operations to ensure the synchronization of SESSION:

request.getSession().setAttribute(“user”, user);

        Therefore, we should pay special attention when operating SESSION! Another suggestion is that we should try not to modify the data in SESSION as much as possible.
        Because Tomcat's SESSION replication communication uses the multicast function to realize the interaction between different servers, it is necessary to enable the multicast function on the server. Windows enables the multicast service by default, while the Linux system does not enable it by default. Yes , we need to enable its multicast function through the following commands:
        route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
        If you need to enable multicast when the server starts, you need to add eht0 to the /etc/sysconfig/static-routes file net 224.0.0.0 netmask 240.0.0.0. For specific multicast concepts, see CCNP related content.
        You can view the multicast status through netstate -g, or you can see it in the route -e command

tomcat configuration session sharing

Guess you like