Re-enable org.jboss.cache.integration.websession.BuddyReplicationFailoverTest
-----------------------------------------------------------------------------
Key: JBCACHE-1472
URL:
https://jira.jboss.org/jira/browse/JBCACHE-1472
Project: JBoss Cache
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 3.0.3.GA
Test has been disabled because of this:
Mircea Markus wrote:
One of them is the next one, on testInvalidateOnFailoverToBackup:
This is the code I am talking about:
InvalidationServlet invs = new InvalidationServlet();
MultipleActionServlet mas = new MultipleActionServlet(sas, invs);
(....)
req = new Request(mgr0, sessionId, mas);
*1+2* req.execute(); (...)
*3*BuddyReplicationAssertions.assertUnrelated(contextHostName,
sessionId, mgr0.getCache());
And some explanation
1) manager0.invalidatesSession (i.e. cache0.remove)
2) manager0 tries to data gravitate session (i.e. cache0.get with
forceDataGrav set to true). This is done last line in Request.execute().
3) asserts that session is no longer present on cache0
Now, the assumption at 3 is not necessarily valid. With some funny
threading and using ASYNC replication, you might have the remote
removeNode command originated from cache0 to run *after* gravitateData
originated at step2. I.e. RemoveNodeCommand being executed after
GravitateDataCommand on cache*1* (buddy of cache0).
This scenario is a known issue -- the RemoveNodeCommand is unicast to the buddy while the
GravitateDataCommand is multicast. JGroups does not impose ordering between unicast and
multicast, so the order from the sender can be lost.
The "last line in Request.execute()" that causes the behavior mimics a portion
of actual AS session replication code, a piece that is a general part of JBoss Web and
outside of the control of the session replication logic.
This JIRA is to examine the test and determine what can be salvaged versus what needs to
be isolated in a separate "known issue" test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira