Possible inactive session issue

[toobstar]

Hi,

Not sure if this is an issue with this library or something relevant to session replication in general..

Let's say:

• We have a L.B. with 2 tomcat instances behind it: TomcatA & TomcatB
• User goes to instance A first and has session created
• They then end up on instance B for all the remainder of their activity. Their session is found via dynamoDB so everything good so far.
• after the session timeout period is hit on instance A, it decides to cleanup the expired session.
• user who is still doing stuff on instance B then loses their session due to cleanup from A

Can this be avoided??

Regards, Toby

[dsjohnsonMaine]

On 7/18/2014 1:57 AM, toobstar wrote:

Hi,

Not sure if this is an issue with this library or something relevant to session replication in general..

Let's say:

• We have a L.B. with 2 tomcat instances behind it: TomcatA & TomcatB
• User goes to instance A first and has session created
• They then end up on instance B for all the remainder of their activity. Their session is found via dynamoDB so everything good so far.
• after the session timeout period is hit on instance A, it decides to cleanup the expired session.
• user who is still doing stuff on instance B then loses their session due to cleanup from A

Can this be avoided??

Regards, Toby

— Reply to this email directly or view it on GitHub https://github.com/aws/aws-dynamodb-session-tomcat/issues/11.

This is one of the things fixed in my mods contributed in pull requests. I now only expire sessions from the DB based on background process cleanup queries directly against the DB. But I'm wondering, if instance A is still available, why is the user being serviced by instance B? You do have sticky session in effect, right?

---

"Oh scholar, if your scholarship benefits not Mankind, you deserve not admiration but contempt." -- Kahlil Gibran

[toobstar]

Firstly on the scenario for when we would have this happen: when doing releases we want to be able cycle servers off then on again with new code. Users should move between nodes without the original node then disrupting the session at a later point.

I need to try the latest version of this library with your commit. Perhaps I'll see some other issues sorted too: namely on a test environment which has had no users on it overnight tomcat is saying we have 100+ active sessions and the dynamo DB session table also has many hundreds of sessions that it knows about. It seems like the ExpiredSessionReaper isn't doing it's job for us. I'm not sure if fixing that will fix the sessions left around on Tomcat but will confirm.

(note: we've been using the "1.02" version on mvnrepository. Not sure which code this has but was published in Feb 2014).

[jamespdean]

Hi Guys.

Just some more detail on Toby's issue. This was confused by the sticky sessions not being sticky for vaery long (fixed) and that we were testing the scenarios of a server being removed from cluster but still running and various alternatives.

What was actually happening is that our session is reloading back from the Store in two cases

• on switching to a new machine (as expected)
• around 30-60 seconds after a request (I suspect the Backup process) triggers a reload from the store.

This was causing the session "last access time" to set back to the "creation time" resulting in our session timeout becoming a session total time rather than inactiivity timeout.

I found the submitted change from "dsjohnsonMaine" for setting the creation time to the lastUpdated time and this has fixed our issues.

For reference we have springSecurity options plus we have some logging actions bound to session events that may be triggering the reload from store after save.

Cheers James (Colleague of toobstar)