"Found no validity info for session" warnings after invalidating session

[GoogleCodeExporter]

Using MSM 1.6.1 with the following config:

<Manager
   className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
   memcachedNodes="n1:node1.domain.name:11211,n2:node2.domain.name:
11211"
   sticky="false"
   lockingMode="auto"
   requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
   sessionBackupAsync="false"
/>

Using Tomcat 7.0.23 and spymemcached 2.7.3

After a session is created, then invalidated, subsequent requests that check 
for a session cause the warning "Found no validity info for session..." until a 
new session is created or the JSESSIONID cookie is manually deleted.

This is undesirable for requests that check for a session but don't necessarily 
expect one to be found, since it generates noise in the output.

To quote your explanation in the discussion group:

"For non-sticky sessions msm stores session lifetime information
(lastAccessed etc.) in a very small object referred to as "validity
info". In this case it tries to load and update the validity info for
the session that got already invalidated, thus it does not know that the
JSESSIONID cookie belongs to an invalidated session and therefore logs
the warning."

Original issue reported on code.google.com by pbell...@whosay.com on 4 Jun 2012 at 5:51

[GoogleCodeExporter]

Thanx for reporting!

Original comment by martin.grotzke on 4 Jun 2012 at 7:35

• Changed state: Accepted

[GoogleCodeExporter]

Is there any workaround for this issue?

Original comment by sgmil...@gmail.com on 8 Jul 2013 at 2:21

[GoogleCodeExporter]

For your reference, here's the related thread on the mailing list: 
https://groups.google.com/d/msg/memcached-session-manager/ab0aoDloaWI/cW3TX9UnTC
wJ

As workaround you could remove the JSESSIONID cookie when you invoked 
session.invalidate(). If you're using some kind of security framework like 
spring-security they should have support for removing the session cookie after 
logout.

AFAIK the reason why tomcat doesn't delete the cookie is that it might be used 
by various webapps (with emptySessionPath=true, which sets path="/" for the 
cookie, useful for e.g. portals).

I'm still not sure what's the preferred solution for msm, e.g. we could add an 
option like 'deleteCookieOnSessionInvalidate="JSESSIONID"', or we always delete 
the session cookie as long as "emptySessionPath" is false and the cookie path 
matches the webapp's context path.

Original comment by martin.grotzke on 9 Jul 2013 at 8:40

[GoogleCodeExporter]

Thanks, I should be able to do that.

Original comment by sgmil...@gmail.com on 9 Jul 2013 at 4:44

[GoogleCodeExporter]

Fixed in git master.

Original comment by martin.grotzke on 9 Jan 2014 at 11:43

• Changed state: Fixed
• Added labels: Milestone-1.7.1

[GoogleCodeExporter]

Original comment by martin.grotzke on 2 Feb 2014 at 2:08

• Added labels: Milestone-1.8.0
• Removed labels: Milestone-1.7.1

[GoogleCodeExporter]

Sorry for reopen this.
This is still happening with v1.8.2 (tomcat 7.0.48 + spymemcached-2.11.1)

  <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
    memcachedNodes="localhost:11211"
    storageKeyPrefix="context"
    sticky="false"
    lockingMode="none"
    requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
    transcoderFactoryClass="de.javakaffee.web.msm.JavaSerializationTranscoderFactory"
    />

I figure out that the problem is the storageKeyPrefix="context", removing this 
attribute solves the "Found no validity info for session" warnings.

Original comment by poles...@gmail.com on 7 Jul 2014 at 9:18

[GoogleCodeExporter]

Can you please open another issue specifically for the combination with 
storageKeyPrefix="context"? Thanks! 

Original comment by martin.grotzke on 8 Jul 2014 at 6:44