9:53 p.m.
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: Clustering, Web (Tomcat) service
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA, JBossAS-4.2.0.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
7:02 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5706) Default session metadata replication too infrequent
[ http://jira.jboss.com/jira/browse/JBAS-5706?page=comments#action_12420595 ]
Dimitris Andreadis commented on JBAS-5706:
------------------------------------------
I think you need to update the 4.2 dtd in trunk, too.
When we publish the dtds we normally do so using the trunk copy as the authoritative one.
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
7:10 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5706) Default session metadata replication too infrequent
[ http://jira.jboss.com/jira/browse/JBAS-5706?page=comments#action_12420596 ]
Dimitris Andreadis commented on JBAS-5706:
------------------------------------------
The testsuite changes are probably causing those 8 failures:
http://hudson.qa.jboss.com/hudson/view/JBoss%20AS/job/JBoss-AS-4.2.x-Test...
But it looks trivial:
org.jboss.deployment.DeploymentException: Failed to parse WEB-INF/jboss-web.xml; - nested
throwable: (org.jboss.deployment.DeploymentException: Invalid XML:
file=file:/qa/services/hudson/hudson_workspace/workspace/JBoss-AS-4.2.x-TestSuite-sun15/Branch_4_2/build/output/jboss-4.2.3.GA/server/all/tmp/deploy/tmp30546class-loading-exp.war//WEB-INF/jboss-web.xml@54:398;
- nested throwable: (org.xml.sax.SAXParseException: The string "--" is not
permitted within comments.))
at org.jboss.web.AbstractWebContainer.parseMetaData(AbstractWebContainer.java:768)
at org.jboss.web.AbstractWebContainer.init(AbstractWebContainer.java:356)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
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
7:39 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5706) Default session metadata replication too infrequent
[ http://jira.jboss.com/jira/browse/JBAS-5706?page=comments#action_12420601 ]
Brian Stansberry commented on JBAS-5706:
----------------------------------------
Sorry about that - copying javadoc into XML was a mistake.
Per our discussion of JBPAPP-944, we decided to not change the DTD and just expose
configuration of this via jboss-web.deployer/META-INF/jboss-service.xml. So, I reverted
the DTD change, which fixes the invalid comment.
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
7:46 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5706) Default session metadata replication too infrequent
[ http://jira.jboss.com/jira/browse/JBAS-5706?page=comments#action_12420603 ]
Dimitris Andreadis commented on JBAS-5706:
------------------------------------------
No problem. So the interval can be configured globally (#3) and also per deployment (#4) ?
:-)
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
8:02 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-5706) Default session metadata replication too infrequent
[ 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
9:56 p.m.
New subject: [JBoss JIRA] Closed: (JBAS-5706) Default session metadata replication too infrequent
[ 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
5833
days inactive
5840
days old
6 comments
2 participants
participants (2)
-
Brian Stansberry (JIRA) -
Dimitris Andreadis (JIRA)