Назад | Перейти на главную страницу

Проблема репликации сеанса Tomcat

TL; DR - имя узла в sessionId не обновляется до текущего имени узла в резервной копии, когда основной выходит из строя.

Версия Tomcat - apache-tomcat-7.0.50

У меня установлено два узла (2 экземпляра моего приложения в 2 отдельных котиках) с конфигурацией репликации сеанса (также используется липкий сеанс). Ниже представлена ​​конфигурация кластера из server.xml, который находится внутри тега Engine. Он одинаков в обоих узлах, за исключением номеров портов:

<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="4050"
        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"/>
    <Interceptor className="org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor"/>\
</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.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>
</Cluster>

Из диспетчера tomcat я вижу, что сеанс (например, D042A0C5E380EB9E500224C87233119C.myNode1) создается на основном узле при входе в систему и правильно реплицируется в резервную копию.

Но как только основной узел выйдет из строя, я ожидаю, что sessionId в резервном узле будет обновлен с использованием текущего имени узла, то есть: D042A0C5E380EB9E500224C87233119C.myNode2

Пример :

Когда пользователь входит в систему:

Node 1 - Primary - jsessionIdSample.node1 
Node 2 - Backup - jsessionIdSample.node1 

Когда один узел 1 выходит из строя (Ожидается) :

Node 1 - - jsessionIdSample.node1 (NODE GOES DOWN) 
Node 2 - Primary - jsessionIdSample.node2 

Но что происходит:

Node 1 - - jsessionIdSample.node1 (NODE DOWN) 
Node 2 - Backup - jsessionIdSample.node1

У меня два вопроса:

1) Правильно ли я понимаю, что идентификатор сеанса должен быть обновлен в резервной копии вскоре после выхода из строя основного узла? Я прочитал документы tomcat, и кажется, что это нужно.

2) Если нужно, не могли бы вы помочь мне с конфигурацией, чтобы это работало?

Я пробовал решения из других вопросов по SO, но ни один из них, похоже, не работает.

Заранее спасибо!

1) Правильно ли я понимаю, что идентификатор сеанса должен быть обновлен в резервной копии вскоре после выхода из строя основного узла? Я прочитал документы tomcat, и кажется, что это нужно.

Ответ: Нет, когда основной выходит из строя, он выходит из строя. у него нет времени размещать что-либо на резервном узле "Я раздавлю". в документе Tomcat говорится, что он будет реплицировать сеансовый кросс-кластер узлов. Что касается части, в которой упоминалось обновление, это означает, что она будет обновляться на всех узлах (а не на том, который уже был разрушен).

2) Если нужно, не могли бы вы помочь мне с конфигурацией, чтобы это работало?

Ответ: Нет данных