February 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2402) Cache operations or transactions should never fail with SuspectException

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2402?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2402: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Cache operations or transactions should never fail with SuspectException > ------------------------------------------------------------------------ > > Key: ISPN-2402 > URL: https://issues.jboss.org/browse/ISPN-2402 > Project: Infinispan > Issue Type: Task > Components: RPC, State transfer > Affects Versions: 5.2.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Alpha1 > > Attachments: vrstt.log > > > This is an extension of ISPN-1896 of sorts, but for all the cache operations that are visible to the user. > After a node leaves, the other nodes that have sent commands to that node should either ignore SuspectExceptions or, if not possible, they should retry the operation (e.g. if they didn't get any response back). > For example, VersionReplStateTransferTest quite often on my machine with a SuspectException, because the versioned prepare command expects a response from the coordinator and the coordinator has just left. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2435) Cache#replace(key, old, new) method doesn't check old value on non-local invocations

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2435?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2435: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Cache#replace(key, old, new) method doesn't check old value on non-local invocations > ------------------------------------------------------------------------------------ > > Key: ISPN-2435 > URL: https://issues.jboss.org/browse/ISPN-2435 > Project: Infinispan > Issue Type: Bug > Components: Core API, Distributed Cache > Affects Versions: 5.1.8.Final, 5.2.0.Beta2 > Reporter: Sanne Grinovero > Assignee: Mircea Markus > Priority: Critical > Fix For: 5.2.2, 5.3.0.Final > > -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2515) org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2515?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2515: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > org.infinispan.container.versioning.VersionedReplStateTransferTest.testStateTransfer fails randomly > --------------------------------------------------------------------------------------------------- > > Key: ISPN-2515 > URL: https://issues.jboss.org/browse/ISPN-2515 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Manik Surtani > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The tests are failing during running testsuite for JDG. > You can find the logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear if the test is run separately. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2516) org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2516?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2516: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest.testNodeDown3 fails randomly > ----------------------------------------------------------------------------------------------------- > > Key: ISPN-2516 > URL: https://issues.jboss.org/browse/ISPN-2516 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The test fails randomly on Rhel6x64 IBM7JDk (for JDG testsuite). > You can find the log here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear when the test is run separately. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2513) org.infinispan.tx.StaleLockRecoveryTest.testStaleLock fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2513?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2513: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > org.infinispan.tx.StaleLockRecoveryTest.testStaleLock fails randomly > -------------------------------------------------------------------- > > Key: ISPN-2513 > URL: https://issues.jboss.org/browse/ISPN-2513 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Final > > > The test fails randomly during Infinispan testsuite run on IBM-JDK7. > You can find the logs here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear when the test is run separately. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2512) org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2512?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2512: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > org.infinispan.lock.singlelock.replicated.pessimistic.InitiatorCrashPessimisticReplTest.testInitiatorNodeCrashesBeforeCommit fails randomly > ------------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-2512 > URL: https://issues.jboss.org/browse/ISPN-2512 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Mircea Markus > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The test failed randomly during last Infinispan testsuite run on Rhel5_x86, OpenJDK6. > You can find the log here: > http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/edg-60-ispn-testsuite... > The bug doesn't appear when the test is run separately. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2511) RemoteExceptionHandlingWithStateTransferTest.testThrowExceptionFromRemoteInterceptor fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2511?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2511: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > RemoteExceptionHandlingWithStateTransferTest.testThrowExceptionFromRemoteInterceptor fails randomly > --------------------------------------------------------------------------------------------------- > > Key: ISPN-2511 > URL: https://issues.jboss.org/browse/ISPN-2511 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Reporter: Anna Manukyan > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EDG6/view/EDG-REPOR... > The test works properly, when run separately. More logs will be provided later. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2510) PrepareCommands should fail on nodes where the cache is not running

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2510?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2510: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > PrepareCommands should fail on nodes where the cache is not running > ------------------------------------------------------------------- > > Key: ISPN-2510 > URL: https://issues.jboss.org/browse/ISPN-2510 > Project: Infinispan > Issue Type: Bug > Components: Distributed Cache, RPC > Affects Versions: 5.2.0.Beta3 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Final > > > When the user stops a cache without stopping the cache manager on that node, subsequent PrepareCommands sent to that node will return a {{SuccessfulResponse}}. > If that node used to the primary owner of the command's modified key, the originator will proceed with the transaction as if it had acquired a lock on that key. It is thus possible for multiple transactions to think they have acquired the key lock at the same time. > On the other hand, in replicated caches is is quite possible that a cache is not running on all the cluster node and yet PrepareCommands are broadcasted to everyone in parallel. So the solution should not involve sending exceptions (which have huge stack traces), and the originator should be able to ignore failures responses from nodes that were not targeted in the first place. -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2539) Initial state transfer timed out for cache testCache - failure during running tests for Async. Executor

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2539?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2539: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > Initial state transfer timed out for cache testCache - failure during running tests for Async. Executor > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-2539 > URL: https://issues.jboss.org/browse/ISPN-2539 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.0.Beta4 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Labels: testsuite_stability > Fix For: 5.2.2, 5.3.0.Alpha1 > > > The issue is the following: > the test checks the work of the asynchronous executors/notifications. > The case is the following: > 2node cluster is created with DIST_ASYNC clustering mode. > The cache configuration is: > {code} > GlobalConfiguration glob = new GlobalConfigurationBuilder() > .globalJmxStatistics().jmxDomain("AsyncNotifExecutorCache").allowDuplicateDomains(true) > .transport().addProperty("configurationFile", "jgroups-tcp.xml"). > distributedSyncTimeout(150000). > strictPeerToPeer(false). > transport(new JGroupsTransport()). > asyncListenerExecutor().addProperty("maxThreads", "5"). > build(); > ConfigurationBuilder c = new ConfigurationBuilder(); > c.clustering().cacheMode(CacheMode.DIST_ASYNC).hash().numOwners(1).transaction().locking().lockAcquisitionTimeout(60000); > Configuration cnf = c.build(); > DefaultCacheManager manager = new DefaultCacheManager(glob); > manager.defineConfiguration(cacheName, cnf); > {code} > The error appears only when the test is running under Tomcat 7 when trying to get the cache object from manager. > The following exception is thrown while the cache getting operation: > {code} > org.infinispan.CacheException: Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.InterruptedException on object of type StateTransferManagerImpl > at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:883) > at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:654) > at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:643) > at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:546) > at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:199) > at org.infinispan.CacheImpl.start(CacheImpl.java:520) > at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:690) > at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:653) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:549) > at com.jboss.datagrid.test.asyncnotif.clustered.AsyncNotificationTest.testKeyCRUD(AsyncNotificationTest.java:77) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270) > at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115) > at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67) > at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81) > at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90) > at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88) > at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135) > at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111) > at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263) > at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185) > at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314) > at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46) > at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147) > at org.junit.runner.JUnitCore.run(JUnitCore.java:157) > at org.junit.runner.JUnitCore.run(JUnitCore.java:136) > at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126) > at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:621) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:722) > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) > at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > Caused by: org.infinispan.CacheException: Initial state transfer timed out for cache testCache on dev61-59071 > at org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete(StateTransferManagerImpl.java:209) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203) > ... 102 more > {code} -- 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

13 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2537) LockCleanupStateTransferTest fails randomly

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2537?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2537: -------------------------------- Fix Version/s: 5.2.2 (was: 5.2.1) > LockCleanupStateTransferTest fails randomly > ------------------------------------------- > > Key: ISPN-2537 > URL: https://issues.jboss.org/browse/ISPN-2537 > Project: Infinispan > Issue Type: Bug > Components: Test Suite > Affects Versions: 5.2.0.Beta4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 5.2.2, 5.3.0.Final > > > LockCleanupStateTransferTest assumes that once the tx is done on one remote node it's done on all of them (and on the originator as well). > It sometimes fails with this stack trace: > {noformat} > java.lang.AssertionError: For cache 0 expected:<0> but was:<1> > at org.junit.Assert.fail(Assert.java:93) > at org.junit.Assert.failNotEquals(Assert.java:647) > at org.junit.Assert.assertEquals(Assert.java:128) > at org.junit.Assert.assertEquals(Assert.java:472) > at org.infinispan.tx.LockCleanupStateTransferTest.testLockReleasedCorrectly(LockCleanupStateTransferTest.java:164) > at org.infinispan.tx.LockCleanupStateTransferTest.testBelatedCommit(LockCleanupStateTransferTest.java:76) > {noformat} -- 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

13 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2013