[JBoss JIRA] (ISPN-6985) FlagsReplicationTest.testScenario random failures
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/ISPN-6985?page=com.atlassian.jira.plugin.... ]
Ivan Straka reassigned ISPN-6985:
---------------------------------
Assignee: Dan Berindei (was: Galder Zamarreño)
> FlagsReplicationTest.testScenario random failures
> -------------------------------------------------
>
> Key: ISPN-6985
> URL: https://issues.jboss.org/browse/ISPN-6985
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 8.2.4.Final
> Reporter: Ivan Straka
> Assignee: Dan Berindei
> Labels: testsuite_stability
>
> {code:java}
> Stacktrace
> java.lang.AssertionError
> at org.infinispan.replication.FlagsReplicationTest.haveSecondaryThreadReleaseLock(FlagsReplicationTest.java:80)
> at org.infinispan.replication.FlagsReplicationTest.testScenario(FlagsReplicationTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> 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:348)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask.run(FutureTask.java:277)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.lang.Thread.run(Thread.java:785)
> Standard Output
> [UnitTestTestNGListener] Test testScenario(org.infinispan.replication.FlagsReplicationTest) failed.
> 11:17:50,928 ERROR (testng-FlagsReplicationTest) [UnitTestTestNGListener] Test testScenario(org.infinispan.replication.FlagsReplicationTest) failed.
> java.lang.AssertionError
> at org.infinispan.replication.FlagsReplicationTest.haveSecondaryThreadReleaseLock(FlagsReplicationTest.java:80)
> at org.infinispan.replication.FlagsReplicationTest.testScenario(FlagsReplicationTest.java:63)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:508)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)[UnitTestTestNGListener] Test suite progress: tests succeeded: 1533, failed: 4, skipped: 0.
> {code}
> [jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-infinispa...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-6985) FlagsReplicationTest.testScenario random failures
by Ivan Straka (JIRA)
Ivan Straka created ISPN-6985:
---------------------------------
Summary: FlagsReplicationTest.testScenario random failures
Key: ISPN-6985
URL: https://issues.jboss.org/browse/ISPN-6985
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 8.2.4.Final
Reporter: Ivan Straka
Assignee: Galder Zamarreño
{code:java}
Stacktrace
java.lang.AssertionError
at org.infinispan.replication.FlagsReplicationTest.haveSecondaryThreadReleaseLock(FlagsReplicationTest.java:80)
at org.infinispan.replication.FlagsReplicationTest.testScenario(FlagsReplicationTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
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:348)
at org.testng.SuiteRunner.access$000(SuiteRunner.java:38)
at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:382)
at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
at java.util.concurrent.FutureTask.run(FutureTask.java:277)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1153)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.lang.Thread.run(Thread.java:785)
Standard Output
[UnitTestTestNGListener] Test testScenario(org.infinispan.replication.FlagsReplicationTest) failed.
11:17:50,928 ERROR (testng-FlagsReplicationTest) [UnitTestTestNGListener] Test testScenario(org.infinispan.replication.FlagsReplicationTest) failed.
java.lang.AssertionError
at org.infinispan.replication.FlagsReplicationTest.haveSecondaryThreadReleaseLock(FlagsReplicationTest.java:80)
at org.infinispan.replication.FlagsReplicationTest.testScenario(FlagsReplicationTest.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
at java.lang.reflect.Method.invoke(Method.java:508)
at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)[UnitTestTestNGListener] Test suite progress: tests succeeded: 1533, failed: 4, skipped: 0.
{code}
[jenkins job|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-infinispa...]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-6971) Use JChannel directly instead of going through MessageDispatcher
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-6971?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on ISPN-6971:
--------------------------------
Another feature of 4.0 is to receive message batches in addition to single message, by implementing {{receive(MessageBatch batch)}} in addition to {{receive(Message msg)}}. Because a message batch is always from the same sender, you could possibly
* iterate through the batch and remove messages
* prioritize messages
* process multiple messages in one go; this reduces lock acquisition, context switching etc
> Use JChannel directly instead of going through MessageDispatcher
> ----------------------------------------------------------------
>
> Key: ISPN-6971
> URL: https://issues.jboss.org/browse/ISPN-6971
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> JGroups changed its serialization in 4.0, and even when using MessageDispatcher we still have to provide a JGroups-style marshaller for deserializing RPC responses. If we used JChannel directly, we could avoid this, and we'd have more control over how we process responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-6971) Use JChannel directly instead of going through MessageDispatcher
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/ISPN-6971?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on ISPN-6971 at 8/29/16 7:22 AM:
---------------------------------------------------------
Another feature of 4.0 is to receive message batches in addition to single messages, by implementing {{receive(MessageBatch batch)}} in addition to {{receive(Message msg)}}. Because a message batch is always from the same sender, you could possibly
* iterate through the batch and remove messages
* prioritize messages
* process multiple messages in one go; this reduces lock acquisition, context switching etc
was (Author: belaban):
Another feature of 4.0 is to receive message batches in addition to single message, by implementing {{receive(MessageBatch batch)}} in addition to {{receive(Message msg)}}. Because a message batch is always from the same sender, you could possibly
* iterate through the batch and remove messages
* prioritize messages
* process multiple messages in one go; this reduces lock acquisition, context switching etc
> Use JChannel directly instead of going through MessageDispatcher
> ----------------------------------------------------------------
>
> Key: ISPN-6971
> URL: https://issues.jboss.org/browse/ISPN-6971
> Project: Infinispan
> Issue Type: Task
> Components: Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Minor
> Fix For: 9.0.0.Beta1
>
>
> JGroups changed its serialization in 4.0, and even when using MessageDispatcher we still have to provide a JGroups-style marshaller for deserializing RPC responses. If we used JChannel directly, we could avoid this, and we'd have more control over how we process responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-4741) ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill randomly fails on RHEL
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/ISPN-4741?page=com.atlassian.jira.plugin.... ]
Ivan Straka reassigned ISPN-4741:
---------------------------------
Assignee: Galder Zamarreño
> ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill randomly fails on RHEL
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4741
> URL: https://issues.jboss.org/browse/ISPN-4741
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.4.Final
> Reporter: Vojtech Juranek
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
>
> {{ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill}} randomly fails (spot on RHEL6, IBM java 6) with ([see details|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FU...]):
> {noformat}
> java.lang.AssertionError: expected:<ConsistentHashV1IntegrationTest-NodeA-42275> but was:<ConsistentHashV1IntegrationTest-NodeE-19755>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.runTest(ConsistentHashV1IntegrationTest.java:124)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill(ConsistentHashV1IntegrationTest.java:155)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-4741) ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill randomly fails on RHEL
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/ISPN-4741?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated ISPN-4741:
------------------------------
Affects Version/s: 8.2.4.Final
> ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill randomly fails on RHEL
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-4741
> URL: https://issues.jboss.org/browse/ISPN-4741
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.4.Final
> Reporter: Vojtech Juranek
> Labels: testsuite_stability
>
> {{ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill}} randomly fails (spot on RHEL6, IBM java 6) with ([see details|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FU...]):
> {noformat}
> java.lang.AssertionError: expected:<ConsistentHashV1IntegrationTest-NodeA-42275> but was:<ConsistentHashV1IntegrationTest-NodeE-19755>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:88)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.runTest(ConsistentHashV1IntegrationTest.java:124)
> at org.infinispan.client.hotrod.ConsistentHashV1IntegrationTest.testCorrectBalancingOfKeysAfterNodeKill(ConsistentHashV1IntegrationTest.java:155)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-6977) NumOwnersNodeCrashInSequenceTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6977?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6977:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4538
> NumOwnersNodeCrashInSequenceTest random failures
> ------------------------------------------------
>
> Key: ISPN-6977
> URL: https://issues.jboss.org/browse/ISPN-6977
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 8.2.4.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> The test (and {{NumOwnersNodeStopInSequenceTest}} as well) uses {{StateSequencerUtil.advanceOnInboundRpc()}}, which replaces the {{PerCacheInboundInvocationHandler}} and rewires all the components.
> The problem is that rewiring {{StateConsumerImpl}} causes it to create a new {{SemaphoreCompletionService}}, but there's no synchronization when reading the field, a "background" task could finish on another thread and release the permit on the old {{SemaphoreCompletionService}} instance.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months
[JBoss JIRA] (ISPN-6984) ConcurrentJoinTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6984?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-6984:
-------------------------------
Status: Open (was: New)
> ConcurrentJoinTest random failures
> ----------------------------------
>
> Key: ISPN-6984
> URL: https://issues.jboss.org/browse/ISPN-6984
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> {{RehashTestBase.testTransactional}} changes the cache membership (in {{ConcurrentJoinTest}}, that means it starts 4 nodes) and waits for the rebalance to finish, then asserts that the keys are owned by the proper nodes.
> Waiting for the rebalance to finish is not enough, however, because entries that are no longer owned are removed asynchronously, *after* the rebalance is finished.
> {noformat}
> 12:00:20,346 TRACE (transport-thread-CJT-NodeL-p1952-t3:[Topology-dist]) [StateConsumerImpl] Received new topology for cache dist, isRebalance = false, isMember = true, topology = CacheTopology{id=11, rebalanceId=6, currentCH=PartitionerConsistentHash:DefaultConsistentHash{ns=256, owners = (8)[CJT-NodeI-14064: 34+28, CJT-NodeJ-23687: 34+32, CJT-NodeK-45647: 30+32, CJT-NodeL-44214: 29+31, CJT-NodeM-42056: 34+33, CJT-NodeN-9760: 34+36, CJT-NodeO-43833: 27+29, CJT-NodeP-5141: 34+35]}, pendingCH=null, unionCH=null, actualMembers=[CJT-NodeI-14064, CJT-NodeJ-23687, CJT-NodeK-45647, CJT-NodeL-44214, CJT-NodeM-42056, CJT-NodeN-9760, CJT-NodeO-43833, CJT-NodeP-5141], persistentUUIDs=[5dc1f506-81b5-4c26-bf9a-f1fb14d54d26, 8943aaa4-2cd1-484a-a6ba-45269e376620, b8cb3e0e-cc6d-4768-8825-8275b06b571e, 5c46f8ac-2007-4286-a64e-580fbc4308eb, 42964274-543b-4c8c-ac39-b74485124aff, cc489f64-345f-4f75-bc60-60fedba26b47, 85b51a75-d9d3-497b-8922-588f8cfa95d3, a5aca3ae-7812-45e9-acc4-392102c7d1da]}
> 12:00:20,346 TRACE (transport-thread-CJT-NodeL-p1952-t3:[Topology-dist]) [StateTransferLockImpl] Signalling topology 11 is installed
> 12:00:20,372 DEBUG (transport-thread-CJT-NodeJ-p1808-t3:[Topology-dist]) [StateConsumerImpl] Removing no longer owned entries for cache dist
> 12:00:20,451 ERROR (testng-CJT:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.CJT.testTransactional
> java.lang.AssertionError: Fail on non-owner cache CJT-NodeJ-23687: dc.get(MagicKey#k2{58/0399D54B/204@CJT-NodeJ-23687}) returned ImmortalCacheEntry{key=MagicKey#k2{58/0399D54B/204@CJT-NodeJ-23687}, value=v2}!
> at org.infinispan.distribution.BaseDistFunctionalTest.assertOwnershipAndNonOwnership(BaseDistFunctionalTest.java:192) ~[test-classes/:?]
> at org.infinispan.distribution.rehash.RehashTestBase.testTransactional(RehashTestBase.java:143) ~[test-classes/:?]
> 12:00:20,459 TRACE (transport-thread-CJT-NodeJ-p1808-t3:[Topology-dist]) [InvalidateCommand] Invalidating keys [MagicKey#k2{58/0399D54B/204@CJT-NodeJ-23687}]
> 12:00:20,465 TRACE (transport-thread-CJT-NodeJ-p1808-t3:[Topology-dist]) [ReadCommittedEntry] Updating entry (key=MagicKey#k2{58/0399D54B/204@CJT-NodeJ-23687} removed=true valid=false changed=true created=false value=v2 metadata=EmbeddedMetadata{version=null}, providedMetadata=null)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 8 months