Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Possible session-timeout issue with Tomcat 7.0.68 #287

Closed
kimmob opened this issue Feb 19, 2016 · 11 comments
Closed

Possible session-timeout issue with Tomcat 7.0.68 #287

kimmob opened this issue Feb 19, 2016 · 11 comments

Comments

@kimmob
Copy link

kimmob commented Feb 19, 2016

We got major issues upgrading from 7.0.67 to 7.0.68. The sessions gets invalidated after around 30 seconds. We do use an old version of the manager so I do not know for sure there is a problem with the latest version.

Using:
x memcached-session-manager-1.6.3.jar
x memcached-session-manager-tc7-1.6.3.jar
x spymemcached-2.8.4.jar

Sorry for reporting a problem with an ancient version, I just thought it could be interesting to investigate the changes in .68.

@magro
Copy link
Owner

magro commented Feb 19, 2016

Can you do me a favor and check the sample https://github.com/magro/memcached-session-manager/tree/master/samples with 68? The tomcat version is a property in the pom.

@kimmob
Copy link
Author

kimmob commented Feb 19, 2016

Sure. Changed to but it to '7.0.68' still starts with:
INFO: Starting Servlet Engine: Apache Tomcat/7.0.47

How can we test if session-timeout have dropped significant after i get the test running? I can look in the memcached console-log perhaps.

(using 7.0.47 "set 1E2A295CE4A1D045DA5769CF76D5AB89-n2 2048 240 187")

@kimmob
Copy link
Author

kimmob commented Feb 19, 2016

@magro
Copy link
Owner

magro commented Feb 19, 2016

Ok, this is in master now, with .68. When running the sample, http://localhost:9090/counter shows a lower session timeout compared to 67. Strange, maybe it's a bug in tomcat?

@kimmob
Copy link
Author

kimmob commented Feb 19, 2016

Maybe I found a bug after all. Why do I always have to be the first one :)

@magro
Copy link
Owner

magro commented Feb 19, 2016

Can you reproduce this issue with plain tomcat and no msm involved?

@kimmob
Copy link
Author

kimmob commented Feb 19, 2016

What I did was removing:
<Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager" memcachedNodes="n1:XXXXX:11211" requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$" sticky="false" />
from context.xml. But of course got stuck to just using one single node instead of the cluster.
Everything started to work as expected without msm. But I haven't tried with any other session-manager, so I guess it's not of much value since a test with another session-manager is what you meant?

@magro
Copy link
Owner

magro commented Feb 19, 2016

When you removed the Manager element you actually used the StandardManager. If it worked as expected in this configuration, what is what I understand from your message, it seems to be an issue with msm.
Not sure what's going on here. If you'd like to further investigate/debug, this would be great!

@kimmob
Copy link
Author

kimmob commented Feb 20, 2016

You understood it correct, it worked with StandardManager, I will try to look into it.

@magro
Copy link
Owner

magro commented Feb 23, 2016

@kimmob The latest tomcat 6.0.45 seems to have a similar issue, just FYI.

@magro
Copy link
Owner

magro commented Feb 23, 2016

@kimmob I just released 1.9.2 with the fix.

@magro magro changed the title Possible issue with Tomcat 7.0.68 Possible session-timeout issue with Tomcat 7.0.68 Apr 25, 2016
magro pushed a commit that referenced this issue Jul 29, 2016
This bug was introduced with commit eddf4c4 (Revert "Use
Context.sessionTimeout to set timeout for new sessions.") because
tomcat no longer invoked the Manager.setMaxInactiveInterval. This
commit hard coded the session timeout without considering the one
set on the Context.

Refs #48, refs #287
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants