[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4949:
-----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> changed the Status of [bug 1165095|https://bugzilla.redhat.com/show_bug.cgi?id=1165095] from NEW to ASSIGNED
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-4949:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1161214, https://bugzilla.redhat.com/show_bug.cgi?id=1165095
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4990) Run all security tests in one maven profile
by Vojtech Juranek (JIRA)
Vojtech Juranek created ISPN-4990:
-------------------------------------
Summary: Run all security tests in one maven profile
Key: ISPN-4990
URL: https://issues.jboss.org/browse/ISPN-4990
Project: Infinispan
Issue Type: Enhancement
Components: Test Suite - Server
Reporter: Vojtech Juranek
Assignee: Vojtech Juranek
Currently some server security tests have to run with profile {{suite.security}}, while other with {{suite.security.manual}}. Unify them to run under same profile and to be executed as part of default server test suite.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4631) NodeAuthentication*PassIT.testReadItemOnJoiningNode fails on RHEL6
by Vojtech Juranek (JIRA)
[ https://issues.jboss.org/browse/ISPN-4631?page=com.atlassian.jira.plugin.... ]
Vojtech Juranek commented on ISPN-4631:
---------------------------------------
Another (probably related) failure from [CI build #761|http://ci.infinispan.org/viewLog.html?buildId=14292&buildTypeId=bt8&tab=buildResultsDiv] :
{noformat}
org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not stop container
at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.stopInternal(ManagedDeployableContainer.java:333)
at org.jboss.as.arquillian.container.CommonDeployableContainer.stop(CommonDeployableContainer.java:124)
at org.jboss.arquillian.container.impl.ContainerImpl.stop(ContainerImpl.java:217)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:178)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$9.perform(ContainerLifecycleController.java:172)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.stopContainer(ContainerLifecycleController.java:171)
[...]
Caused by: java.net.ConnectException: JBAS012144: Could not connect to http-remoting://127.0.0.1:10190. The connection timed out
at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
{noformat}
> NodeAuthentication*PassIT.testReadItemOnJoiningNode fails on RHEL6
> ------------------------------------------------------------------
>
> Key: ISPN-4631
> URL: https://issues.jboss.org/browse/ISPN-4631
> Project: Infinispan
> Issue Type: Bug
> Components: Integration , Security
> Affects Versions: 7.0.0.Beta1
> Reporter: Dan Berindei
> Assignee: Vojtech Juranek
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.CR1
>
>
> Failures appear only on the RHEL agents in CI, both in NodeAuthenticationKrbPassIT and NodeAuthenticationMD5PassIT:
> {noformat}
> java.lang.AssertionError: expected:<test_value> but was:<null>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.infinispan.test.integration.security.embedded.AbstractNodeAuthentication.testReadItemOnJoiningNode(AbstractNodeAuthentication.java:94)
> at org.infinispan.test.integration.security.embedded.NodeAuthenticationKrbPassIT.testReadItemOnJoiningNode(NodeAuthenticationKrbPassIT.java:71)
> {noformat}
> The failure in {{NodeAuthentication*FailIT.testReadItemOnJoiningNode}} is almost certainly related:
> {noformat}
> java.lang.Exception: Unexpected exception, expected<org.infinispan.manager.EmbeddedCacheManagerStartupException> but was<java.lang.Exception>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at org.infinispan.test.integration.security.embedded.AbstractNodeAuthentication.testReadItemOnJoiningNode(AbstractNodeAuthentication.java:94)
> at org.infinispan.test.integration.security.embedded.NodeAuthenticationMD5FailIT.testReadItemOnJoiningNode(NodeAuthenticationMD5FailIT.java:55)
> {noformat}
> http://ci.infinispan.org/viewLog.html?buildId=10776&tab=buildResultsDiv&b...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-4949:
--------------------------------
{quote}
Therefore, we can add another layer or make the JGroups view optionally 'reliable'.
{quote}
I don't like your use of the word _reliable_; it suggests view installation is _unreliable_, which is not true. View installation is _reliable_, but failure detection itself is _unreliable_ and will always be. There is no way to write a reliable failure detection in an asynchronous messaging system [1].
In other words, when the failure detection _thinks_ a member has failed, a new view will be installed _reliably_ (but without consensus).
{quote}
I haven't considered FD, as the detection of such split would take looong anyway, I was really rather thinking of protocols where any node failure detection is constant (therefore, FD would have to suspect all other nodes when a failure is detected, and use VERIFY_SUSPECT to check who is still alive).
{quote}
FD_ALL or FD_ALL2 come closest to this, but they are _unreliable_ as well.
{quote}
Not sure if I understand; The algorithm installs the view as soon as it gets the ack or timeout from all members.
{quote}
I think according to the semantics implied by your use of the term _reliable view installation_, you *cannot* install a view unless you get an ack from all members in it. So in order to install view 1-50, you'd have to get an ack from members [1..50]. If a single member, e.g. 32, doesn't ack the view, you cannot install that view. In this case, I think retrying to get 50 acks until all acks have been received or a new view is to be installed would probably be best.
[1] http://www.cs.yale.edu/homes/aspnes/pinewiki/FailureDetectors.html
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4949) Split brain: inconsistent data after merge
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4949?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-4949:
-----------------------------------
{quote}The fact that Infinispan cannot handle this scenario doesn't mean the view installation algorithm is wrong{quote}
I am not saying that it's wrong - Infinispan partition handling was designed based on incorrect assumptions.
Let's call the functionality Infinispan requires/expects 'reliable view'. We call either
a) build up the functionality in Infinispan itself
b) provide this service by JGroups as framework, and be reusable by other applications as wel
Currently there is JGroups view layer and Infinispan cache members layer. Therefore, we can add another layer or make the JGroups view *optionally* 'reliable'.
{quote}I believe it's better to notify members of a crashed member as soon as possible, so the application can react.{quote}
In general case, yes. But Infinispan would have to handle that anyway (and eager notification would not really help), therefore, delegating such general functionality makes sense IMO.
{quote}I'm not even sure JGRP-1901 makes sense: imagine a partition in a 100 node view: view 1-100 splits into 1-50 and 51-100. If the first partition has to be created going from 1-100 -> 1-50, then the view installation has to be delayed until all members have acked the new view. This means we have to wait until the failure detection suspected members 51-100 before we could install view 1-50 ! This could take a long time, especially if we use FD (over TCP).{quote}
I haven't considered FD, as the detection of such split would take looong anyway, I was really rather thinking of protocols where any node failure detection is constant (therefore, FD would have to suspect all other nodes when a failure is detected, and use VERIFY_SUSPECT to check who is still alive).
{quote}This could even get worse: if some members in the second partition are suspended due to GC or temp network problems, then they might come in and out of sight (suspect-unsuspect-suspect), so an algorithm such as outlined in JGRP-1901 would never come to a conclusion and install a new view.{quote}
Not sure if I understand; The algorithm installs the view as soon as it gets the ack or timeout from all members. When the node comes out of sight for a long time, it is expelled from the view - sure it can rejoin later. However, when it has already acked another view (from the second half) it should not ack the view from first half before leaving the second half.
> Split brain: inconsistent data after merge
> ------------------------------------------
>
> Key: ISPN-4949
> URL: https://issues.jboss.org/browse/ISPN-4949
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
>
> 1) cluster A, B, C, D splits into 2 parts:
> A, B (coord A) finds this out immediately and enters degraded mode with CH [A, B, C, D]
> C, D (coord D) first detects that B is lost, gets view A, C, D and starts rebalance with CH [A, C, D]. Segment X is primary owned by C (it had backup on B but this got lost)
> 2) D detects that A was lost as well, therefore enters degraded mode with CH [A, C, D]
> 3) C inserts entry into X: all owners (only C) is present, therefore the modification is allowed
> 4) cluster is merged and coordinator finds out that the max stable topology has CH [A, B, C, D] (it is the older of the two partitions' topologies, got from A, B) - logs 'No active or unavailable partitions, so all the partitions must be in degraded mode' (yes, all partitions are in degraded mode, but write has happened in the meantime)
> 5) The old CH is broadcast in newest topology, no rebalance happens
> 6) Inconsistency: read in X may miss the update
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4989) infinispan-transport thread name is undefined
by Takayoshi Kimura (JIRA)
[ https://issues.jboss.org/browse/ISPN-4989?page=com.atlassian.jira.plugin.... ]
Takayoshi Kimura updated ISPN-4989:
-----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/3080
> infinispan-transport thread name is undefined
> ---------------------------------------------
>
> Key: ISPN-4989
> URL: https://issues.jboss.org/browse/ISPN-4989
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 7.0.1.Final
> Reporter: Takayoshi Kimura
> Assignee: Takayoshi Kimura
> Priority: Minor
>
> In stack trace, all infinispan-transport threads appear as "undefined".
> {noformat}
> "undefined" prio=10 tid=0x00007f536528e800 nid=0x7da waiting on condition [0x00007f534835b000]
> {noformat}
> We can add the {{thread-name-pattern="%G %f-%t"}} on the infinispan-transport thread factory.
> {noformat}
> %t - emit the per-factory thread sequence number
> %g - emit the global thread sequence number
> %f - emit the factory sequence number
> %i - emit the thread ID
> %G - emit the thread group name
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4989) infinispan-transport thread name is undefined
by Takayoshi Kimura (JIRA)
Takayoshi Kimura created ISPN-4989:
--------------------------------------
Summary: infinispan-transport thread name is undefined
Key: ISPN-4989
URL: https://issues.jboss.org/browse/ISPN-4989
Project: Infinispan
Issue Type: Enhancement
Components: Server
Affects Versions: 7.0.1.Final
Reporter: Takayoshi Kimura
Assignee: Takayoshi Kimura
Priority: Minor
In stack trace, all infinispan-transport threads appear as "undefined".
{noformat}
"undefined" prio=10 tid=0x00007f536528e800 nid=0x7da waiting on condition [0x00007f534835b000]
{noformat}
We can add the {{thread-name-pattern="%G %f-%t"}} on the infinispan-transport thread factory.
{noformat}
%t - emit the per-factory thread sequence number
%g - emit the global thread sequence number
%f - emit the factory sequence number
%i - emit the thread ID
%G - emit the thread group name
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months
[JBoss JIRA] (ISPN-4988) Infinispan state transfer tests fail with Azul JDK
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-4988?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-4988:
------------------------------------
Assignee: Dan Berindei
> Infinispan state transfer tests fail with Azul JDK
> --------------------------------------------------
>
> Key: ISPN-4988
> URL: https://issues.jboss.org/browse/ISPN-4988
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.0.1.Final
> Reporter: Vitalii Chepeliuk
> Assignee: Dan Berindei
> Labels: testsuite_stability
>
> Lot of ST tests fail with
> {noformat}
> 2014-11-16 10:16:50,867 ERROR [UnitTestTestNGListener] (testng-DistSyncNonTxStateTransferTest) Test testRemoveIfMatchFail(org.infinispan.xsite.statetransfer.DistSyncNonTxStateTransferTest) failed.
> java.lang.AssertionError: expected:<ok> but was:<Unable to pushState to 'NYC'. org.infinispan.util.concurrent.TimeoutException: Timed out after 20 minutes waiting for a response from NYC (sync, timeout=1200000)>
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.startStateTransfer(BaseStateTransferTest.java:447)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testStateTransferWithNoReplicatedOperation(BaseStateTransferTest.java:372)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveIfMatchFail(BaseStateTransferTest.java:167)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Test suite progress: tests succeeded: 21, failed: 140, skipped: 0.
> {noformat}
> or
> {noformat}
> java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:188)
> at org.infinispan.commons.util.concurrent.NotifyingFutureImpl.get(NotifyingFutureImpl.java:73)
> at org.infinispan.xsite.BackupReceiverImpl.invokeRemotelyInLocalSite(BackupReceiverImpl.java:215)
> at org.infinispan.xsite.BackupReceiverImpl.handleStateTransferControl(BackupReceiverImpl.java:89)
> at org.infinispan.xsite.BackupReceiverDelegator.handleStateTransferControl(BackupReceiverDelegator.java:37)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.performInLocalSite(XSiteStateTransferControlCommand.java:41)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher$3.run(CommandAwareRpcDispatcher.java:250)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from DistSyncOnePhaseTxStateTransferTest-NodeAJ-18700, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:44)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:364)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:165)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:525)
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:290)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:325)
> at org.infinispan.remoting.rpc.RpcManagerImpl$2.call(RpcManagerImpl.java:321)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> ... 3 more
> Caused by: org.infinispan.commons.CacheException: Already receiving state from LON
> at org.infinispan.xsite.statetransfer.XSiteStateConsumerImpl.startStateTransfer(XSiteStateConsumerImpl.java:64)
> at org.infinispan.xsite.statetransfer.XSiteStateTransferControlCommand.perform(XSiteStateTransferControlCommand.java:59)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:208)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:81)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:265)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:209)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:460)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:377)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:250)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:677)
> at org.jgroups.JChannel.up(JChannel.java:733)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029)
> at org.jgroups.protocols.relay.RELAY2.up(RELAY2.java:419)
> at org.jgroups.protocols.RSVP.up(RSVP.java:201)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:394)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:383)
> at org.jgroups.protocols.tom.TOA.up(TOA.java:121)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:1042)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:234)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1064)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:779)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:619)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:297)
> at org.jgroups.protocols.Discovery.up(Discovery.java:277)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1572)
> at org.jgroups.protocols.TP$MyHandler.run(TP.java:1791)
> ... 3 more
> {noformat}
> or
> {noformat}
> 2014-11-15 22:02:52,185 ERROR [UnitTestTestNGListener] (testng-DistSyncOnePhaseTxStateTransferTest) Test testRemoveNonExisting(org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest) failed.
> java.util.concurrent.TimeoutException: Timed out waiting for event before-start
> at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:43)
> at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:33)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest$XSiteStateProviderControl.await(BaseStateTransferTest.java:783)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testConcurrentOperation(BaseStateTransferTest.java:300)
> at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testRemoveNonExisting(BaseStateTransferTest.java:179)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> More info from jenkins jobs here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-63-ispn-testsuit...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
11 years, 4 months