SecurityContextImpl removed from HttpSession during tomcat shutdown

[colini]

Hello,

I'm using Spring Security 3.0.5 on Tomcat 6 for our web application. Recently I've been implementing a failover system using this memcached-based session manager: http://code.google.com/p/memcached-session-manager/

This is how I have been testing the failover process w/ two Tomcats, A and B. A and B are running behind a load balancer.
* User logs into Tomcat A. SecurityContextImpl is visible in his session.
* User's session is automatically replicated to memcached. User's SecurityContextImpl also visible (serialized) in memcached.
* To simulate a failure, Tomcat A is shutdown.
* The load balancer redirects User to Tomcat B.
* At this point User should also be logged into Tomcat B, but this is not the case. He's redirected to the login page.

After digging around I determined that at some point during Tomcat A shutdown the user's SecurityContextImpl is removed from his session. Other session data remains unchanged. I can verify this by examining the session data in memcached. Since the SecurityContextImpl is gone, after failover Tomcat B sees the user as un-authenticated.

If I kill Tomcat A instead of cleanly shutting it down the SessionContextImpl remains in the session (and memcached) and the failover to Tomcat B succeeds.

Now I'm trying to determine what is removing the SeesionContextImpl. Is this a feature of Spring Security? A listener of some sort? I've had no luck figuring this out. Any help greatly appreciated.

thanks,
Colin

[dlmiles]

context.xml ? <Context ....>

	<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="true" distributable="true" debug="0">
		<Store className="org.apache.catalina.session.FileStore"/>
	</Manager>

Have you configured your <Manager ....> in a suitable way ? Do you only have the single <Manager> element, I'm not sure myself of TC allows multiple per context.

For me with the above config and a single TC non-clustered setup I am able to stop and start TC and the client's HTTP session continues to live. Maybe it is worth testing if this is the case with your application and the rest of your TC setup for a non-clustered setup.

This way you can bias your investigation away from spring-security and TC and look more at the custom <Manager> setup.

[colini]

My context.xml:

<Context>
    <Loader delegate="true"/>
    
    <ResourceLink global="jdbc/cdb.mysql" name="jdbc/cdb" type="javax.sql.DataSource"/>
   
    <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
          memcachedNodes="n1:172.23.240.53:11211,n2:172.23.240.53:11212"
          failoverNodes="n1"
          requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    />
</Context>

This is the only Manager I've defined. I assume this replaces the default Tomcat session manager but I will double-check that (Tomcat behavior has surprised me plenty of times...)

I'll try again with Tomcat's PersistentManager and FIleStore and see if the SecurityContextImpl is persisted.

Thanks,
Colin

[mattjanks16]

I'm curious if you ever resolved the issue with the Spring Security context being removed. I'm seeing the exact same behavior with my current setup as well.