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

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.