Notice that the com.sun.enterprise.ee.web.sessmgmt.ReplicationState instances printed to the server.log are being used for multiple purposes: one is to save (replicate) a given session to the replication partner instance, and the other is to query the cluster for a requested session.
In the server.log, the former use of ReplicationState is prefixed with:
JxtaBackingStoreImpl>>createHttpReplicationState:transmitState
and the latter is prefixed with:
JxtaBackingStoreImpl>>findSessionViaBroadcast:queryInputState
Also notice that in the former case, the ReplicationState's "isExpired" is always "false" (if the session were already expired, there would be no use in replicating it).
The reason the ReplicationState's "isExpired" is "true" when used in query mode is that the sender does not know anything about the requested session other than its session id and version. "isExpired" is a function of the session's lastAccessedTime, and the session manager's configured maxInactiveInterval. Since the sender knows nothing about the session's lastAccessedTime, "isExpired" evaluates to "true", but it really does not have any meaning in this mode.
[Message sent by forum member 'jluehe' (jluehe)]
http://forums.java.net/jive/thread.jspa?messageID=269589