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

[Brian Stansberry (JIRA)]

     [ https://issues.jboss.org/browse/JBCACHE-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated JBCACHE-1472:
--------------------------------------

    Assignee:     (was: Brian Stansberry)

    
> Re-enable org.jboss.cache.integration.websession.BuddyReplicationFailoverTest
> -----------------------------------------------------------------------------
>
>                 Key: JBCACHE-1472
>                 URL: https://issues.jboss.org/browse/JBCACHE-1472
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Brian Stansberry
>             Fix For: 3.3.0.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, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira