[jbosscache-issues] [JBoss JIRA] Created: (JBCACHE-1472) Re-enable org.jboss.cache.integration.websession.BuddyReplicationFailoverTest

[Brian Stansberry (JIRA)]

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