JBAS-2377 Coordinated Session Expiration

[brian.stansberry]

(Continuation of discussion from the JIRA issue http://jira.jboss.com/jira/browse/JBAS-2377

I've been thinking a bit about what's reasonable behavior and have a different opinion than when I opened this issue.

I think the big flaw in what we do now is when the background thread runs, we load sessions from the cache, and thereafter those sessions are treated as if they had been accessed on that node. If we can add a simple transient boolean "activeLocally" to the session, and only set it to true if the session is actually acessed, that will go a long way. When the background thread runs and the session isn't active locally, just evict it from the cache, but don't do the expire stuff that generates notifications.

If the session is "activeLocally" on more than one cluster node, I think it's more than reasonable to send out the HttpSessionEvents on all the nodes where it has been touched. IMHO, trying to devise a way to only issue the events on one server is not needed. If we can find an easy way to do it, fine, but if its a hassle, I think its unnecessary.

[brian.stansberry]

On a related issue, I've been thinking about how to prevent session expirations on other nodes if the session is being used somewhere, but the usage isn't enough to cause replication (e.g no setAttribute calls).

In ClusteredSession we could add a field transient long replicationTime, which is updated every time the replication code kicks in. Then as part of the process of deciding whether to replicate we check that field. If the elapsed time is > 80-90% of the session timeout time, we go ahead and replicate.

I still like the idea of instrumenting the session body and replicating only the access time with each call, but that's going to take some work, while the above is simple to do and can go into 4.0.4.

[ben.wang]

1. I still thinks if we can query JBossCacheService before we do expiration (from the background thread) to see emitting event nofitication only when I am the coordinator is the easiest way. Of coruse, JBossCacheService will need to subscribe to TreeCacheListener for ViewChange event to update the topology. :-)

2. As for related issue for a temporary solution (before switching to instrumenting the session), replicationTime approach is doable. Of course, it only covers about 80% of the use cases?

-Ben

[brian.stansberry]

Ok, now I understand what you meant. Using a word like 'coordinator' when you meant 'coordinator' threw me off ;)

1. I still thinks if we can query JBossCacheService before we do expiration (from the background thread) to see emitting event nofitication only when I am the coordinator is the easiest way. Of coruse, JBossCacheService will need to subscribe to TreeCacheListener for ViewChange event to update the topology. :-)

The ViewChange approach would be pretty easy and sounds like the way to go for users who want a guaranteed single notification :) But it would have to be a configurable option, because with this approach the event would be issued on the coordinator, not the server where the session was actually being used.

I think the default should be to issue notifications wherever the session was accessed, wit multiple notifications if need be. I definitely don't think we should be issuing them on every node in the cluster.

2. As for related issue for a temporary solution (before switching to instrumenting the session), replicationTime approach is doable. Of course, it only covers about 80% of the use cases?

How so? If the session is accessed, and it hasn't been replicated in a long time, it gets replicated whether or not it's dirty.