The processExpires() algorithm is ignoring the fact that the local copy of the session is outdated and the serialized session data in the cache may have a later lastAccessedTime. The only time the serialized data in the cache is used to update the local copy of the session is if the end user touches the session

Synopsis of the problem:

1) Session repl configured to use SET_AND_GET, which generates the most frequent possible replication events in the current scheme.
2) Session 123 created on server A and replicated to B.
3) Server B's processExpires() gets called, resulting in 123 being hydrated from the cache and placed in the local sessions map.
4) User uses 123 on A, resulting in replication to B.
5) Replicated session is never deserialized on B, as session is never accessed on B.
6) B's processExpires() runs again. Checks the old version of 123 sitting in the local map. Ignores fact that replication events have happened and the local copy is stale. Session is expired.
7) HttpSessionListener on B gets a session destroyed event, causing unwanted state changes to occur in the user's app.

I haven't empirically confirmed this, but what I expect will also happen is:

8) If the app's response to the session destroyed event on B doesn't causing a state change in A that kills 123 there, user will continue using 123 on server A, causing fresh replication traffic to B.
9) Steps 3-7 repeat themselves.