[jboss-jira] [JBoss JIRA] Closed: (JBAS-5706) Default session metadata replication too infrequent

[Brian Stansberry (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBAS-5706?page=all ]

Brian Stansberry closed JBAS-5706.
----------------------------------

    Resolution: Done

This has been fixed by changing default maximum interval between requests, in seconds, after which a request will trigger replication of the session's timestamp and other metadata regardless of whether the request has otherwise made the session dirty. Previously this was hardcoded at 80% of the session's expiration time (i.e. what would be returned by HttpSession.getMaxInactiveInterval()). Now the default is 60 seconds, and the value has been made configurable.

The server-wide default for this value can be changed by adding an attribute like the following to the server/.../deploy/jboss-web.deployer/META-INF/jboss-service.xml file:

<attribute name="MaxUnreplicatedInterval">30</attribute>

Following is a description of the meaning of the attribute:

"Clustering only: Determines the maximum interval between requests, in
  seconds, after which a request will trigger replication of the session's
  timestamp and other metadata regardless of whether the request has otherwise
  made the session dirty. Such replication ensures that other nodes in the
  cluster are aware of the most recent value for the session's timestamp
  and won't incorrectly expire an unreplicated session upon failover. It also
  results in correct values for HttpSession.getLastAccessedTime() calls
  following failover.

  The cost of this metadata replication depends on the configured
  replication-granularity. With <code>SESSION</code>, the session's
  attribute map is replicated along with the metadata, so it can be fairly
  costly. With other granularities, the metadata object is replicated
  separately from the attributes and only contains a String, and a few longs,
   ints and booleans.
   
   A value of 0 means the metadata will be replicated whenever the session is
   accessed. A value of -1 means the metadata will be replicated only if some
   other activity during the request (e.g. modifying an attribute) has
   resulted in other replication work involving the session. A positive value
   greater than the HttpSession.getMaxInactiveInterval() value will be treated
   as a likely misconfiguration and converted to 0; i.e. replicate the
   metadata on every request.
    
   Default value if unconfigured is 60 seconds."

> Default session metadata replication too infrequent
> ---------------------------------------------------
>
>                 Key: JBAS-5706
>                 URL: http://jira.jboss.com/jira/browse/JBAS-5706
>             Project: JBoss Application Server
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Web (Tomcat) service, Clustering
>    Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-4.2.2.GA
>            Reporter: Brian Stansberry
>         Assigned To: Brian Stansberry
>             Fix For: JBossAS-4.2.3.GA
>
>
> ClusteredSession includes logic to skip replicating session metadata if the only thing changed is the timestamp.  This is driven by the ClusteredSession.maxUnreplicatedFactor property, which represents the percentage of the session's maxInactiveInterval the metadata should be allowed to go unreplicated.
> The default value for this property (80) is far too high.  It basically means a session's timestamp will go unreplicated for 80% of its lifespan. If no request comes in during the remaining 20%, and then a failover occurs, the failover server will see a timestamp for the session that is older than the expiration time, and the session will be invalidated.
> This problem does not exist in AS 5, which replicates the timestamp independently from other metadata, sending it at least once per minute.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira