You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Tomcat Random <to...@gmail.com> on 2013/08/27 18:27:32 UTC

session-replication fails on restart or kill

Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on
each server. Physical loadbalancer with sticky sessions. No proxy servers.

I've set up session-replication using the delta-manager. I can confirm it
works just lovely when the LB switches over from one box to the other.
Using a test get/set session value servlet, the manager app reports the
primary session value on the box where it was set, and the identical backup
value on the other box. So everything appears good there.

The problem is if, as a crash test, I stop/restart or kill the tomcat
service on the box with the primary session: the backup session on the
other box gets removed. So, as you'd imagine, when the LB swaps to the
non-dead server the session value is gone. Not so good there.

Shouldn't the backup session value remain? Isn't that sort of the whole
point. Any ideas? It would seem box 1 and box 2 can communicate enough to
create backup session values and detect the death of the other node. Why
would the backup session value be lost?

Thanks,
Alec

Re: session-replication fails on restart or kill

Posted by Mark Thomas <ma...@apache.org>.
On 27/08/2013 23:02, Tomcat Random wrote:
> NP, glad to contribute a little. The FAQ was helpful but it's a little
> confusing. I'd like to clean it up and add to the part that specifically
> addresses two boxes two nodes on Linux. Would that be alright?

Sure. You'll need to create an account on the wiki and then let us know
(replying here is fine) the account name so you can be added to list of
contributors - that will enable you to edit stuff. This extra step is
necessary to avoid the spam that was created when anyone with an account
was allowed to edit the wiki.

Mark

> 
> Thanks,
> Alec
> 
> 
> On Tue, Aug 27, 2013 at 5:52 PM, Mark Thomas <ma...@apache.org> wrote:
> 
>> On 27/08/2013 22:41, Tomcat Random wrote:
>>> In a great moment of DUH, I realized I had the expireSessionsOnShutdown
>> to
>>> true.
>>>
>>> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>>>                                expireSessionsOnShutdown="false"
>>>                                notifyListenersOnReplication="true"/>
>>>
>>> All working nicely now.
>>
>> Thanks for posting the solution. It makes the archives much more useful
>> for the next person that finds themselves facing the same issue.
>>
>> Mark
>>
>>
>>>
>>>
>>>
>>> On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random <tomcat.random@gmail.com
>>> wrote:
>>>
>>>> Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance
>> on
>>>> each server. Physical loadbalancer with sticky sessions. No proxy
>> servers.
>>>>
>>>> I've set up session-replication using the delta-manager. I can confirm
>> it
>>>> works just lovely when the LB switches over from one box to the other.
>>>> Using a test get/set session value servlet, the manager app reports the
>>>> primary session value on the box where it was set, and the identical
>> backup
>>>> value on the other box. So everything appears good there.
>>>>
>>>> The problem is if, as a crash test, I stop/restart or kill the tomcat
>>>> service on the box with the primary session: the backup session on the
>>>> other box gets removed. So, as you'd imagine, when the LB swaps to the
>>>> non-dead server the session value is gone. Not so good there.
>>>>
>>>> Shouldn't the backup session value remain? Isn't that sort of the whole
>>>> point. Any ideas? It would seem box 1 and box 2 can communicate enough
>> to
>>>> create backup session values and detect the death of the other node. Why
>>>> would the backup session value be lost?
>>>>
>>>> Thanks,
>>>> Alec
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: session-replication fails on restart or kill

Posted by Tomcat Random <to...@gmail.com>.
NP, glad to contribute a little. The FAQ was helpful but it's a little
confusing. I'd like to clean it up and add to the part that specifically
addresses two boxes two nodes on Linux. Would that be alright?

Thanks,
Alec


On Tue, Aug 27, 2013 at 5:52 PM, Mark Thomas <ma...@apache.org> wrote:

> On 27/08/2013 22:41, Tomcat Random wrote:
> > In a great moment of DUH, I realized I had the expireSessionsOnShutdown
> to
> > true.
> >
> > <Manager className="org.apache.catalina.ha.session.DeltaManager"
> >                                expireSessionsOnShutdown="false"
> >                                notifyListenersOnReplication="true"/>
> >
> > All working nicely now.
>
> Thanks for posting the solution. It makes the archives much more useful
> for the next person that finds themselves facing the same issue.
>
> Mark
>
>
> >
> >
> >
> > On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random <tomcat.random@gmail.com
> >wrote:
> >
> >> Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance
> on
> >> each server. Physical loadbalancer with sticky sessions. No proxy
> servers.
> >>
> >> I've set up session-replication using the delta-manager. I can confirm
> it
> >> works just lovely when the LB switches over from one box to the other.
> >> Using a test get/set session value servlet, the manager app reports the
> >> primary session value on the box where it was set, and the identical
> backup
> >> value on the other box. So everything appears good there.
> >>
> >> The problem is if, as a crash test, I stop/restart or kill the tomcat
> >> service on the box with the primary session: the backup session on the
> >> other box gets removed. So, as you'd imagine, when the LB swaps to the
> >> non-dead server the session value is gone. Not so good there.
> >>
> >> Shouldn't the backup session value remain? Isn't that sort of the whole
> >> point. Any ideas? It would seem box 1 and box 2 can communicate enough
> to
> >> create backup session values and detect the death of the other node. Why
> >> would the backup session value be lost?
> >>
> >> Thanks,
> >> Alec
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Re: session-replication fails on restart or kill

Posted by Mark Thomas <ma...@apache.org>.
On 27/08/2013 22:41, Tomcat Random wrote:
> In a great moment of DUH, I realized I had the expireSessionsOnShutdown to
> true.
> 
> <Manager className="org.apache.catalina.ha.session.DeltaManager"
>                                expireSessionsOnShutdown="false"
>                                notifyListenersOnReplication="true"/>
> 
> All working nicely now.

Thanks for posting the solution. It makes the archives much more useful
for the next person that finds themselves facing the same issue.

Mark


> 
> 
> 
> On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random <to...@gmail.com>wrote:
> 
>> Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on
>> each server. Physical loadbalancer with sticky sessions. No proxy servers.
>>
>> I've set up session-replication using the delta-manager. I can confirm it
>> works just lovely when the LB switches over from one box to the other.
>> Using a test get/set session value servlet, the manager app reports the
>> primary session value on the box where it was set, and the identical backup
>> value on the other box. So everything appears good there.
>>
>> The problem is if, as a crash test, I stop/restart or kill the tomcat
>> service on the box with the primary session: the backup session on the
>> other box gets removed. So, as you'd imagine, when the LB swaps to the
>> non-dead server the session value is gone. Not so good there.
>>
>> Shouldn't the backup session value remain? Isn't that sort of the whole
>> point. Any ideas? It would seem box 1 and box 2 can communicate enough to
>> create backup session values and detect the death of the other node. Why
>> would the backup session value be lost?
>>
>> Thanks,
>> Alec
>>
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: session-replication fails on restart or kill

Posted by Tomcat Random <to...@gmail.com>.
In a great moment of DUH, I realized I had the expireSessionsOnShutdown to
true.

<Manager className="org.apache.catalina.ha.session.DeltaManager"
                               expireSessionsOnShutdown="false"
                               notifyListenersOnReplication="true"/>

All working nicely now.



On Tue, Aug 27, 2013 at 12:27 PM, Tomcat Random <to...@gmail.com>wrote:

> Tomcat 7.0.42 / RHEL 6 / Two physical servers, with one tomcat instance on
> each server. Physical loadbalancer with sticky sessions. No proxy servers.
>
> I've set up session-replication using the delta-manager. I can confirm it
> works just lovely when the LB switches over from one box to the other.
> Using a test get/set session value servlet, the manager app reports the
> primary session value on the box where it was set, and the identical backup
> value on the other box. So everything appears good there.
>
> The problem is if, as a crash test, I stop/restart or kill the tomcat
> service on the box with the primary session: the backup session on the
> other box gets removed. So, as you'd imagine, when the LB swaps to the
> non-dead server the session value is gone. Not so good there.
>
> Shouldn't the backup session value remain? Isn't that sort of the whole
> point. Any ideas? It would seem box 1 and box 2 can communicate enough to
> create backup session values and detect the death of the other node. Why
> would the backup session value be lost?
>
> Thanks,
> Alec
>