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

[Brian Stansberry (JIRA)]

    [ http://jira.jboss.com/jira/browse/JBAS-5706?page=comments#action_12420605 ] 
            
Brian Stansberry commented on JBAS-5706:
----------------------------------------

Yes, as #4 is a hacky workaround to avoid changing the DTD. The per deployment config is like this, in jboss-web.xml

<jboss-web>
   <replication-config>
      <!-- We don't like the default of 60 seconds; 2 minutes is adequate -->
      <max-unreplicated-interval>120</max-unreplicated-interval>
   </replication-config>
</jboss-web>

The max-unreplicated-interval element is not specified in the DTD, so if you add a DOCTYPE and try to validate that xml, it's illegal. But the WebMetaData parsing code handles it with no problem. The o.j.test.cluster.test.SimpleTestCase actually deploys a war with such a jboss-web.xml.

I suppose a community 4.2.3 release could have different rules from EAP and go ahead and update the DTD. And then EAP users have it too. It's all kind of metaphysical. ;)

> 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