[JBoss JIRA] (ISPN-8191) CacheException in scattered cache when incrementing version
by Radim Vansa (JIRA)
Radim Vansa created ISPN-8191:
---------------------------------
Summary: CacheException in scattered cache when incrementing version
Key: ISPN-8191
URL: https://issues.jboss.org/browse/ISPN-8191
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Radim Vansa
Assignee: Radim Vansa
When the topology changes after {{SDI.checkTopology}} check and we try to increment version, {{ScatteredVersionManager}} throws CacheException. We should rather throw OutdatedTopologyException because we know that the command was running with outdated topology.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-8097) ScatteredCrashInSequenceTest.testSplit failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8097?page=com.atlassian.jira.plugin.... ]
Radim Vansa updated ISPN-8097:
------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/5317
> ScatteredCrashInSequenceTest.testSplit failures
> ------------------------------------------------
>
> Key: ISPN-8097
> URL: https://issues.jboss.org/browse/ISPN-8097
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Labels: testsuite_stability
>
> In PrefetchInterceptor, when looking up who could be the new owner of the segment (during key/value transfer) the forked command did not have topologyId set. Therefore the cache topology (9) vs. command topology check was not executed, and the command has thrown AOLE.
> STI caught this AOLE but already with the original command (topology 10), so it has decided that topology 11 is needed and waiting for this has timed out.
> In the solution in PR we set the topology id which in turn results in throwing OTE with requested topology 10 directly.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-6952) JCacheTwoCachesBasicOpsTest.testRemovedListener fails
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6952?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6952:
----------------------------------
Git Pull Request: https://github.com/infinispan/infinispan/pull/5372 (was: https://github.com/infinispan/infinispan/pull/5331)
> JCacheTwoCachesBasicOpsTest.testRemovedListener fails
> -----------------------------------------------------
>
> Key: ISPN-6952
> URL: https://issues.jboss.org/browse/ISPN-6952
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Critical
> Labels: testsuite_stability
> Attachments: JCacheTwoCachesBasicOpsTest_20161106.log.gz
>
>
> http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=804...
> {noformat}
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> 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.runSequentially(SuiteRunner.java:343)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:305)
> at org.testng.SuiteRunner.run(SuiteRunner.java:254)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1224)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1149)
> at org.testng.TestNG.run(TestNG.java:1057)
> at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:115)
> at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.executeMulti(TestNGDirectoryTestSuite.java:205)
> at org.apache.maven.surefire.testng.TestNGDirectoryTestSuite.execute(TestNGDirectoryTestSuite.java:108)
> at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:111)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> ------- Stdout: -------
> [TestSuiteProgress] Test starting: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> 12:50:19,634 ERROR (testng-JCacheTwoCachesBasicOpsTest) [TestSuiteProgress] Test failed: org.infinispan.jcache.JCacheTwoCachesBasicOpsTest.testRemovedListener
> java.lang.AssertionError: expected [1] but found [2]
> at org.testng.Assert.fail(Assert.java:94)
> at org.testng.Assert.failNotEquals(Assert.java:494)
> at org.testng.Assert.assertEquals(Assert.java:123)
> at org.testng.Assert.assertEquals(Assert.java:370)
> at org.testng.Assert.assertEquals(Assert.java:380)
> at org.infinispan.jcache.AbstractTwoCachesBasicOpsTest.testRemovedListener(AbstractTwoCachesBasicOpsTest.java:302)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)[TestSuiteProgress] Tests succeeded: 19, failed: 1, skipped: 0
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3918:
------------------------------------
Indeed, fixed.
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.2.0.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Dan Berindei edited comment on ISPN-3918 at 8/10/17 4:20 AM:
-------------------------------------------------------------
I found another failure mode while trying to work around this issue in {{NonTxPutIfAbsentDuringLeaveStressTest}} (I was also trying to merge it with {{NonTxPutIfAbsentDuringJoinStressTest}} into a {{NonTxPutIfAbsentDuringRebalanceStressTest}}, so the stack traces in the attached log _NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz_ don't match master).
Say {{owners(k) = AB}} in topology {{t}}, and {{owners(k) = BA}} in topology {{t+1}}. In the following scenario, {{putIfAbsent}} fails in thread _C-app1_ and _C-app2_ with different values:
# _C-app1_: start putIfAbsent(k, v1)
# _C-app1_: send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: send backup request for putIfAbsent(k, v1) to B
# _A-remote1_: write k=v1
# _C-remote1_: receive null for putIfAbsent(k, v1)
# _C-app2_: start putIfAbsent(k, v2)
# _C-app2_: send putIfAbsent(k, v2) to A (primary)
# _A-remote2_: receive putIfAbsent(k, v1)
# _A-remote2_: read v1 from data container, fail the command
# _C-remote2_: receive v1 for putIfAbsent(k, v2)
# *_C-app2_: return v1 (put was unsuccessful)*
# _B-remote1_: install topology t+1, B is now primary owner
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: check topology, send OutdatedTopologyException ack to C
# _C-remote3_: install topology t+1
# _C-app3_: start putIfAbsent(k, v3)
# _C-app3_: send putIfAbsent(k, v3) to B (primary)
# _B-remote3_: receive putIfAbsent(k, v3)
# _B-remote3_: send backup request for putIfAbsent(k, 3) to A
# _B-remote3_: write k=v3
# _C-remote3_: receive null for putIfAbsent(k, v3)
# _A-remote3_: receive backup request for putIfAbsent(k, v3)
# _A-remote3_: write k=v3
# _A-remote3_: send backup ack for putIfAbsent(k, v3) to C
# _C-remote3_: receive backup ack for putIfAbsent(k, v3)
# *_C-app3_: return null (put was successful)*
# _B-remote1_: retry, B is now primary owner
# _B-remote1_: read v3 from data container, fail the command
# _C-remote1_: receive v3 for putIfAbsent(k, v1)
# *_C-app1_: return v3 (put was unsuccessful)*
I think both this scenario and the previous one are worse than the initial report of seeing {{null}}, because we're not respecting the {{READ_COMMITTED}} isolation level (a transaction is seeing a value that was never committed).
was (Author: dan.berindei):
I found another failure mode while trying to work around this issue in {{NonTxPutIfAbsentDuringLeaveStressTest}} (I was also trying to merge it with {{NonTxPutIfAbsentDuringJoinStressTest}} into a {{NonTxPutIfAbsentDuringRebalanceStressTest}}, so the stack traces in the attached log _NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz_ don't match master).
Say {{owners(k) = AB}} in topology {{t}}, and {{owners(k) = BA}} in topology {{t+1}}. In the following scenario, {{putIfAbsent}} fails in thread _C-app1_ and _C-app2_ with different values:
# _C-app1_: start putIfAbsent(k, v1)
# _C-app1_: send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: send backup request for putIfAbsent(k, v1) to B
# _A-remote1_: write k=v1
# _C-remote1_: receive null for putIfAbsent(k, v1)
# _C-app2_: start putIfAbsent(k, v2)
# _C-app2_: send putIfAbsent(k, v2) to A (primary)
# _A-remote2_: receive putIfAbsent(k, v1)
# _A-remote2_: read v1 from data container, fail the command
# _C-remote2_: receive v1 for putIfAbsent(k, v2)
# *_C-app2_: return v1 (put was unsuccessful)*
# _B-remote1_: install topology t+1, B is now primary owner
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: check topology, send OutdatedTopologyException ack to C
# _C-remote3_: install topology t+1
# _C-app3_: start putIfAbsent(k, v3)
# _C-app3_: send putIfAbsent(k, v3) to B (primary)
# _B-remote3_: receive putIfAbsent(k, v3)
# _B-remote3_: send backup request for putIfAbsent(k, 3) to A
# _B-remote3_: write k=v3
# _C-remote3_: receive null for putIfAbsent(k, v3)
# _A-remote3_: receive backup request for putIfAbsent(k, v3)
# _A-remote3_: write k=v3
# _A-remote3_: send backup ack for putIfAbsent(k, v3) to C
# _C-remote3_: receive backup ack for putIfAbsent(k, v3)
# *_C-app3_: return null (put was successful)*
# _B-remote1_: retry, B is now primary owner
# _B-remote1_: read v2 from data container, fail the command
# _C-remote1_: receive v2 for putIfAbsent(k, v1)
# *_C-app1_: return v2 (put was unsuccessful)*
I think both this scenario and the previous one are worse than the initial report of seeing {{null}}, because we're not respecting the {{READ_COMMITTED}} isolation level (a transaction is seeing a value that was never committed).
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.2.0.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-3918:
-----------------------------------
Dan at point 29, the DC on B should contain v3, shouldn't it? Not that it would change much...
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.2.0.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3918:
------------------------------------
I found another failure mode while trying to work around this issue in {{NonTxPutIfAbsentDuringLeaveStressTest}} (I was also trying to merge it with {{NonTxPutIfAbsentDuringJoinStressTest}} into a {{NonTxPutIfAbsentDuringRebalanceStressTest}}, so the stack traces in the attached log _NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz_ don't match master).
Say {{owners(k) = AB}} in topology {{t}}, and {{owners(k) = BA}} in topology {{t+1}}. In the following scenario, {{putIfAbsent}} fails in thread _C-app1_ and _C-app2_ with different values:
# _C-app1_: start putIfAbsent(k, v1)
# _C-app1_: send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: send backup request for putIfAbsent(k, v1) to B
# _A-remote1_: write k=v1
# _C-remote1_: receive null for putIfAbsent(k, v1)
# _C-app2_: start putIfAbsent(k, v2)
# _C-app2_: send putIfAbsent(k, v2) to A (primary)
# _A-remote2_: receive putIfAbsent(k, v1)
# _A-remote2_: read v1 from data container, fail the command
# _C-remote2_: receive v1 for putIfAbsent(k, v2)
# *_C-app2_: return v1 (put was unsuccessful)*
# _B-remote1_: install topology t+1, B is now primary owner
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: check topology, send OutdatedTopologyException ack to C
# _C-remote3_: install topology t+1
# _C-app3_: start putIfAbsent(k, v3)
# _C-app3_: send putIfAbsent(k, v3) to B (primary)
# _B-remote3_: receive putIfAbsent(k, v3)
# _B-remote3_: send backup request for putIfAbsent(k, 3) to A
# _B-remote3_: write k=v3
# _C-remote3_: receive null for putIfAbsent(k, v3)
# _A-remote3_: receive backup request for putIfAbsent(k, v3)
# _A-remote3_: write k=v3
# _A-remote3_: send backup ack for putIfAbsent(k, v3) to C
# _C-remote3_: receive backup ack for putIfAbsent(k, v3)
# *_C-app3_: return null (put was successful)*
# _B-remote1_: retry, B is now primary owner
# _B-remote1_: read v2 from data container, fail the command
# _C-remote1_: receive v2 for putIfAbsent(k, v1)
# *_C-app1_: return v2 (put was unsuccessful)*
I think both this scenario and the previous one are worse than the initial report of seeing {{null}}, because we're not respecting the {{READ_COMMITTED}} isolation level (a transaction is seeing a value that was never committed).
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: consistency
> Fix For: 9.2.0.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months
[JBoss JIRA] (ISPN-5730) SingleFileStoreStressTest.testFileTruncation fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5730?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-5730:
-------------------------------
Labels: testsuite_stability (was: )
> SingleFileStoreStressTest.testFileTruncation fails randomly
> -----------------------------------------------------------
>
> Key: ISPN-5730
> URL: https://issues.jboss.org/browse/ISPN-5730
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Roman Macor
> Labels: testsuite_stability
>
> Test org.infinispan.persistence.file.SingleFileStoreStressTest.testFileTruncation fails randomly with:
> Stacktrace
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:33)
> at org.infinispan.persistence.file.SingleFileStoreStressTest.testFileTruncation(SingleFileStoreStressTest.java:268)
> 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)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 4 months