handling tomcat failover - session transition to new node

[Jason Britton <jb...@gmail.com>]

Questions on particulars of session fail over in my on going quest for zero
downtime deployments -

My current plan is to use JDBCStore for persisting to a database table
shared by all tomcats powering apps.  But this has brought up a couple
concerns...  If while a tomcat node is being shut down and triggered by
this shut down, tomcat starts writing out session data to the JDBCStore, a
request from a client that was using that node comes in, mod_jk tries to
route the request to the node that is shutting down but mod_jk's configured
connect_timeout times out waiting and mod_jk then routes to another node
(hopefully that's how this works).  A different active tomcat node now
receives the request and tries to reconstitute the user's session from the
same shared JDBCStore, but what if the first tomcat node is not finished
shutting down and has not finished writing out this particular user's
session data yet?  How can we ensure that session data will be there?

>From looking at the config of the Manager, there is a maxIdleBackup
parameter that I imagine could be set to 0 but I'm a little wary of the
possible performance implications.  Its description: The time interval (in
seconds) since the last access to a session before it is eligible for being
persisted to the session store, or -1 to disable this feature. By default,
this feature is disabled.  Even if this was ok from a performance
perspective, once a session was initially persisted, would its session data
be updated in the session store on subsequent changes/requests?

I've read about some folks configuring valves for shared in-memory caches
(redis), I'm not sure I want to go that route at this point.

Any thoughts would be much appreciated, happy holidays!

Jason

Re: handling tomcat failover - session transition to new node

[Mark Thomas <ma...@apache.org>]

On 22/12/2015 16:22, Jason Britton wrote:
> Questions on particulars of session fail over in my on going quest for zero
> downtime deployments -
> 
> My current plan is to use JDBCStore for persisting to a database table
> shared by all tomcats powering apps.  But this has brought up a couple
> concerns...  If while a tomcat node is being shut down and triggered by
> this shut down, tomcat starts writing out session data to the JDBCStore, a
> request from a client that was using that node comes in, mod_jk tries to
> route the request to the node that is shutting down but mod_jk's configured
> connect_timeout times out waiting and mod_jk then routes to another node
> (hopefully that's how this works).  A different active tomcat node now
> receives the request and tries to reconstitute the user's session from the
> same shared JDBCStore, but what if the first tomcat node is not finished
> shutting down and has not finished writing out this particular user's
> session data yet?  How can we ensure that session data will be there?

With the set-up you describe, you can't.

If you were using clustering, you could configure the cluster to
replicate any changes in the session before the request is completed.
That way, for any completed request, the cluster is guaranteed to be up
to date

> From looking at the config of the Manager, there is a maxIdleBackup
> parameter that I imagine could be set to 0 but I'm a little wary of the
> possible performance implications.  Its description: The time interval (in
> seconds) since the last access to a session before it is eligible for being
> persisted to the session store, or -1 to disable this feature. By default,
> this feature is disabled.  Even if this was ok from a performance
> perspective, once a session was initially persisted, would its session data
> be updated in the session store on subsequent changes/requests?

Yes. The best way to dig into this is to look at the source code.

> I've read about some folks configuring valves for shared in-memory caches
> (redis), I'm not sure I want to go that route at this point.
> 
> Any thoughts would be much appreciated, happy holidays!

A custom valve that triggered session persistence at the end of every
request? You'd probably need a custom persistence manager so the
necessary hooks were exposed.

A tomcat cluster is, essentially an in-memory, distributed session
cache. If you want a pure Tomcat solution, that is probably the way to go.

Mark


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