Session timeout event doesn't fired

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Session Timeout Event

What is the expected output? What do you see instead?
Session Timeout Event Fired, Doesn't fired

What version of the product are you using? On what operating system?
memcached-session-manager 1.6.5, tomcat 7.0.42, Cent OS 6.4, Windows 7 64bit, 
Spring Security Framework + HttpSessionListener

Please provide any additional information below.
if session.invalidate() called, session destroyed event to be fired.
but... 
When the session expires, the actual session itself has expired and the user 
can not use.
but, Session timeout event doesn't fired.

While not using memcached-session-manager, for the same environment, it is 
handled properly.

Original issue reported on code.google.com by cj84...@gmail.com on 4 Sep 2013 at 2:32

[GoogleCodeExporter]

+ JDK 1.7 or JDK 1.6 

Original comment by cj84...@gmail.com on 4 Sep 2013 at 2:38

[GoogleCodeExporter]

Do you use sticky or non-sticky configuration?

Original comment by martin.grotzke on 4 Sep 2013 at 8:14

[GoogleCodeExporter]

     <Manager className="de.javakaffee.web.msm.MemcachedBackupSessionManager"
            memcachedNodes="n1:localhost:11211"
            sticky="false"
            sessionBackupAsync="true"
            memcachedProtocol="binary"
                        operationTimeout="10000"
                        sessionBackupTimeout="10000"
            lockingMode="none"
            requestUriIgnorePattern=".*\.(ico|png|gif|jpg|css|js)$"
            transcoderFactoryClass="de.javakaffee.web.msm.serializer.kryo.KryoTranscoderFactory"
            customConverter="kr.co.infraware.polaris.persistent.kryo.LocaleCustomization"
    />

It's My Configuration.
i used to non-sticky configuration.

Original comment by cj84...@gmail.com on 4 Sep 2013 at 8:27

[GoogleCodeExporter]

Ok, then it makes sense. Non-sticky session are removed from the local session 
map at the end of a request. This is needed to prevent stale session data: 
assume that tomcat1 serves request1 and sets foo=bar in the session. Afterwards 
tomcat2 handles request2 and sets foo=baz. Then tomcat1 handles request3, now 
the session should return foo=baz. If tomcat1 would keep the session locally it 
would not get the changes done by other instances. Therefore in a non-sticky 
configuration sessions are only stored in memcached and only loaded to handle a 
request.

This behaviour should be documented, this is what can be improved. But that it 
works how it works is "by design" and not a bug - sorry for that ;-)

Original comment by martin.grotzke on 4 Sep 2013 at 9:56

[GoogleCodeExporter]

yeah. I got it.

I have implemented in a way that avoids this problem.

I solve this problem, but the problem is still present in the environment 
sticky.

1. Multi-WAS
2. msm is assumed to be a sticky configuration.

L4 or http server environment is set to non-sticky problem arises when the 
session expires.
(A user -> A WAS request -> C WAS connect -> after session invalid time A WAS 
Session expired -> A WAS Connect -> A Session Expired)

If you think there is a problem if this portion. document should be updated.

Original comment by cj84...@gmail.com on 5 Sep 2013 at 5:32

[GoogleCodeExporter]

1. Multi WAS -> Multi WAS, non-sticky loadbalancing

Original comment by cj84...@gmail.com on 5 Sep 2013 at 5:33

[GoogleCodeExporter]

A non-sticky loadbalancer in combination with sticky tomcat/msm does not make 
sense - you'll get stale sessions.
Is the HttpSessionListener also not invoked when you just access one tomcat and 
wait for session expiration?

Original comment by martin.grotzke on 5 Sep 2013 at 11:17

[GoogleCodeExporter]

I do not know why it would stale.
anyway, If the answer to the question is ok.

one tomcat, wait for expiration...

then not invoked.

Original comment by cj84...@gmail.com on 6 Sep 2013 at 5:31

[GoogleCodeExporter]

Hi cj84..@gmail.com

could you tell me  how u fix this top ?

Thanks.

Original comment by haroldy...@gmail.com on 8 Apr 2015 at 5:29

[GoogleCodeExporter]

At the moment we reveted the configuration sticky on balancer and sticky on 
memcached. An initial workaround was the implementation of a thread that 
destroy the expired sessions.

Original comment by denis.si...@gmail.com on 9 Apr 2015 at 5:43