Hazelcast Web SessionListener

[mailmatt...@gmail.com]

Hi,

I am using hazelcast and hazelcast-wm 3.5 with a WebLogic container.

Would it be possible for someone clarify the behaviour of the session expiry?

I would like to set the time-to-live-seconds on the distributed map to 0 and use the session timeout configured in the web application XML.

The documentation indicates this is supported:

Hazelcast automatically removes sessions from the cluster if the sessions are expired on the Web Container. This removal is done by com.hazelcast.web.SessionListener, which is an implementation of javax.servlet.http.HttpSessionListener.
Default session expiration configuration depends on the Servlet Container that is being used. You can also define it in your web.xml.

The Javadoc on WebFilter#destroySession also implies this:

@param invalidate {@code true} if the session has been invalidated and should be destroyed on all nodes in the cluster; otherwise, {@code false} to only remove the session globally if this node was the final node referencing it

The highlighted part is of particular interest to me as I cannot work out how this is being enforced. The only consequence I can see of setting this flag to false is that the DeleteSessionEntryProcessor will set the session state back on the map against the same key (instead of removing it).

Thus the behaviour is as follows:

1. Session expires after time defined in web.xml (session-config/session-timeout).
2. Container invokes com.hazelcast.web#sessionDestroyed.
3. WebFilter#destroySession invoked (with invalidate flag set to false).

So far, so good.

However on the on the next request following destruction of the session:

1. The browser will still send the hazelcast web session cookie in the HTTP request (with the same session ID).
2. WebFilter.RequestWrapper#getOrCreateHazelcastSession is invoked on first session access.
3. #getSessionWithId will return null, because the session will have been removed from the sessions map following the timeout (WebFilter#destroySession).
   
4. A new HazelcastHttpSession object will be instantiated (via createNewSession and createHazelcastHttpSession).
   
5. The HazelcastHttpSession#buildLocalCache will populate all session attributes from the session id read from the cookie in step one. (Oops!)

From the code I can understand why 

Thus nothing appears to have expired - the session and all attributes remain in tact.

Obviously you can get different behaviours by altering the time-to-live-seconds of the distributed map to be higher/lower/equal to the session-timeout, but as stated at the start I would prefer (if possible) to configure this in one place.

Thank you in advance for any contributions.

[mailmatt...@gmail.com]

On Monday, August 3, 2015 at 3:49:56 PM UTC+1, mailmatt...@gmail.com wrote:

From the code I can understand why the current behaviour is occurring... but I cannot see how the documented behaviour is enforced.

Oops for me... tailed off mid sentence. 

[Bilal Yasar]

Hi there,

This is known issue which is solved by https://github.com/hazelcast/hazelcast/pull/5868

Also we have fixed some issues current hazelcast repo. So you can use hazelcast 3.6-SNAPSHOT or 3.5.2-SNAPSHOT version. ( you can get from maven snapshot repo)

Or you can wait for official 3.5.2 release which will be in 1-2 weeks afaik.

thanks for report.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at http://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/751b8354-bf3d-4ee7-8542-3521e8340776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mailmatt...@gmail.com]

Fantastic - thank you Bilal.

I need to get better at checking GitHub...!

if (invalidate || sessionState.getJvmIds().isEmpty()) {

That makes perfect sense - it is at this point I was getting confused when debugging.

Matter of fact I am about to switch to 3.5.2-SNAPSHOT anyway (for another reason) - but this is extra good news.