[JBoss JIRA] (ISPN-5150) Eager near cache tests randomly failing
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5150?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5150:
----------------------------------------
@Dan, thanks for the logs. Unfortunately it shows little because events are executed by "HotRod-client-async-pool-" thread. I'm changing that in this JIRA so that the async thread name includes the test name as well.
> Eager near cache tests randomly failing
> ---------------------------------------
>
> Key: ISPN-5150
> URL: https://issues.jboss.org/browse/ISPN-5150
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.1.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 7.1.0.CR1
>
> Attachments: LazyNearCacheTest_pr_galderz_t_5130_20150115.log
>
>
> expectNearGetValue() failing randomly in eager near cache tests randomly, e..g
> http://ci.infinispan.org/viewLog.html?buildId=22924&buildTypeId=bt9&tab=b...
> {code}
> java.lang.AssertionError: expected:<v1> but was:<null>
> 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.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
> at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetNearCache(EagerNearCacheTest.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> In this case, the tests afterwards fail with:
> {code}
> java.lang.AssertionError: [org.infinispan.client.hotrod.near.MockNearCacheService$MockPutIfAbsentEvent{key=1, value=VersionedValueImpl{version=1, value=v1}}] expected:<0> but was:<1>
> 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:245)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNoNearEvents(AssertsNearCache.java:71)
> at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetUpdatesNearCache(EagerNearCacheTest.java:59)
> {code}
> We also see a similar failure in ClusterEagerNearCacheTest
> http://ci.infinispan.org/viewLog.html?buildId=22966&tab=buildResultsDiv&b...
> {code}
> java.lang.AssertionError: expected:<v1> but was:<null>
> 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.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
> at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.expectNearCacheUpdates(ClusterEagerNearCacheTest.java:65)
> at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.testNearCacheUpdatesSeenByAllClients(ClusterEagerNearCacheTest.java:58)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5150) Eager near cache tests randomly failing
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-5150?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-5150:
----------------------------------------
I've replicated locally with a loop of executing tests in this package, but it's not enough to know how the value disappeared. One option would be that the near cache stopped and it was cleared but there's no such thing happening. I'll add more logging and retry.
> Eager near cache tests randomly failing
> ---------------------------------------
>
> Key: ISPN-5150
> URL: https://issues.jboss.org/browse/ISPN-5150
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.1.0.Beta1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 7.1.0.CR1
>
> Attachments: LazyNearCacheTest_pr_galderz_t_5130_20150115.log
>
>
> expectNearGetValue() failing randomly in eager near cache tests randomly, e..g
> http://ci.infinispan.org/viewLog.html?buildId=22924&buildTypeId=bt9&tab=b...
> {code}
> java.lang.AssertionError: expected:<v1> but was:<null>
> 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.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
> at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetNearCache(EagerNearCacheTest.java:37)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> {code}
> In this case, the tests afterwards fail with:
> {code}
> java.lang.AssertionError: [org.infinispan.client.hotrod.near.MockNearCacheService$MockPutIfAbsentEvent{key=1, value=VersionedValueImpl{version=1, value=v1}}] expected:<0> but was:<1>
> 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:245)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNoNearEvents(AssertsNearCache.java:71)
> at org.infinispan.client.hotrod.near.EagerNearCacheTest.testGetUpdatesNearCache(EagerNearCacheTest.java:59)
> {code}
> We also see a similar failure in ClusterEagerNearCacheTest
> http://ci.infinispan.org/viewLog.html?buildId=22966&tab=buildResultsDiv&b...
> {code}
> java.lang.AssertionError: expected:<v1> but was:<null>
> 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.near.AssertsNearCache.assertGetKeyValue(AssertsNearCache.java:168)
> at org.infinispan.client.hotrod.near.AssertsNearCache.expectNearGetValue(AssertsNearCache.java:85)
> at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.expectNearCacheUpdates(ClusterEagerNearCacheTest.java:65)
> at org.infinispan.client.hotrod.near.ClusterEagerNearCacheTest.testNearCacheUpdatesSeenByAllClients(ClusterEagerNearCacheTest.java:58)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5152) Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5152?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated ISPN-5152:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1182561
> Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-5152
> URL: https://issues.jboss.org/browse/ISPN-5152
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Listeners
> Affects Versions: 7.1.0.Beta1
> Reporter: Jiří Holuša
>
> Use case (done via declarative config, but doesn't matter):
> 1) Add CustomInterceptor1 with position="FIRST"
> 2) Add CustomInterceptor2 with position="LAST"
> 3) Add CustomInterceptor3 with position="OTHER_THAN_FIRST_OR_LAST"
> Expected that order of interceptors 1, 3, 2, or at least it would work. Unfortunately, this configuration fails during start of CacheManager with:
> org.infinispan.commons.CacheConfigurationException: ISPN000225: Custom interceptor 'testpackage.CustomInterceptor3' doesn't specify a position
> Thus (and by looking at the code), option OTHER_THAN_FIRST_OR_LAST doesn't do anything.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5152) Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
by Jiří Holuša (JIRA)
[ https://issues.jboss.org/browse/ISPN-5152?page=com.atlassian.jira.plugin.... ]
Jiří Holuša updated ISPN-5152:
------------------------------
Description:
Use case (done via declarative config, but doesn't matter):
1) Add CustomInterceptor1 with position="FIRST"
2) Add CustomInterceptor2 with position="LAST"
3) Add CustomInterceptor3 with position="OTHER_THAN_FIRST_OR_LAST"
Expected that order of interceptors 1, 3, 2, or at least it would work. Unfortunately, this configuration fails during start of CacheManager with:
org.infinispan.commons.CacheConfigurationException: ISPN000225: Custom interceptor 'testpackage.CustomInterceptor3' doesn't specify a position
Thus (and by looking at the code), option OTHER_THAN_FIRST_OR_LAST doesn't do anything.
was:
Use case (done via declarative config, but doesn't matter):
1) Add CustomInterceptor1 with position="FIRST"
2) Add CustomInterceptor2 with position="LAST"
3) Add CustomInterceptor3 with position="OTHER_THAN_FIRST_OR_LAST"
Expected that order of interceptors 1, 3, 2, or at least it would work. Unfortunately, this configuration fails during start of CacheManager with:
org.infinispan.commons.CacheConfigurationException: ISPN000225: Custom interceptor 'testgram.CustomInterceptor1' doesn't specify a position
Thus (and by looking at the code), option OTHER_THAN_FIRST_OR_LAST doesn't do anything.
> Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-5152
> URL: https://issues.jboss.org/browse/ISPN-5152
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Listeners
> Affects Versions: 7.1.0.Beta1
> Reporter: Jiří Holuša
>
> Use case (done via declarative config, but doesn't matter):
> 1) Add CustomInterceptor1 with position="FIRST"
> 2) Add CustomInterceptor2 with position="LAST"
> 3) Add CustomInterceptor3 with position="OTHER_THAN_FIRST_OR_LAST"
> Expected that order of interceptors 1, 3, 2, or at least it would work. Unfortunately, this configuration fails during start of CacheManager with:
> org.infinispan.commons.CacheConfigurationException: ISPN000225: Custom interceptor 'testpackage.CustomInterceptor3' doesn't specify a position
> Thus (and by looking at the code), option OTHER_THAN_FIRST_OR_LAST doesn't do anything.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-5152) Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
by Jiří Holuša (JIRA)
Jiří Holuša created ISPN-5152:
---------------------------------
Summary: Custom interceptor with Position.OTHER_THAN_FIRST_OR_LAST causes CacheManager start to fail
Key: ISPN-5152
URL: https://issues.jboss.org/browse/ISPN-5152
Project: Infinispan
Issue Type: Bug
Components: Core, Listeners
Affects Versions: 7.1.0.Beta1
Reporter: Jiří Holuša
Use case (done via declarative config, but doesn't matter):
1) Add CustomInterceptor1 with position="FIRST"
2) Add CustomInterceptor2 with position="LAST"
3) Add CustomInterceptor3 with position="OTHER_THAN_FIRST_OR_LAST"
Expected that order of interceptors 1, 3, 2, or at least it would work. Unfortunately, this configuration fails during start of CacheManager with:
org.infinispan.commons.CacheConfigurationException: ISPN000225: Custom interceptor 'testgram.CustomInterceptor1' doesn't specify a position
Thus (and by looking at the code), option OTHER_THAN_FIRST_OR_LAST doesn't do anything.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4717) Hot Rod 2.0 should add error codes for suspected nodes and stopping/stopped caches
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4717?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4717:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1039090|https://bugzilla.redhat.com/show_bug.cgi?id=1039090] from ON_QA to VERIFIED
> Hot Rod 2.0 should add error codes for suspected nodes and stopping/stopped caches
> ----------------------------------------------------------------------------------
>
> Key: ISPN-4717
> URL: https://issues.jboss.org/browse/ISPN-4717
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.2.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.CR1, 7.0.0.Final
>
>
> The way Hot Rod protocol deals with suspected exceptions is hacky. It inspects the error message to detect whether a SuspectException has been passed in. Instead, suspect exceptions should have a dedicated error code so that clients can handle appropriately.
> On top of that, another exception that should be handled more silently and failover is when a cache is stopping or is stopped. -Currently, this produces the following log messages without affecting functionality- Scrap that, it does get propagated to the client without being able to failover, so it's a bug:
> {code}2014-09-11 08:11:04,984 ERROR [HotRodDecoder] (HotRodServerWorker-6-1) ISPN005003: Exception reported
> java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:94)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1490)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:968)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:960)
> at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:485)
> at org.infinispan.server.core.AbstractProtocolDecoder.put(AbstractProtocolDecoder.scala:252)
> at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeValue(AbstractProtocolDecoder.scala:207)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:73)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at java.lang.Thread.run(Thread.java:744)
> 2014-09-11 08:11:04,990 ERROR [HotRodDecoder] (HotRodServerWorker-6-1) ISPN005009: Unexpected error before any request parameters read
> io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:417)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:149)
> at org.infinispan.server.core.AbstractProtocolDecoder.channelRead(AbstractProtocolDecoder.scala:471)
> at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:332)
> at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:318)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:787)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:125)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:507)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:464)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:378)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:350)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:116)
> at java.lang.Thread.run(Thread.java:744)
> Caused by: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.server.hotrod.HotRodDecoder.createServerException(HotRodDecoder.scala:204)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:77)
> at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:61)
> at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:362)
> ... 12 more
> Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:94)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:71)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:33)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:71)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1490)
> at org.infinispan.cache.impl.CacheImpl.putInternal(CacheImpl.java:968)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:960)
> at org.infinispan.cache.impl.DecoratedCache.put(DecoratedCache.java:485)
> at org.infinispan.server.core.AbstractProtocolDecoder.put(AbstractProtocolDecoder.scala:252)
> at org.infinispan.server.core.AbstractProtocolDecoder.org$infinispan$server$core$AbstractProtocolDecoder$$decodeValue(AbstractProtocolDecoder.scala:207)
> at org.infinispan.server.core.AbstractProtocolDecoder.decodeDispatch(AbstractProtocolDecoder.scala:73)
> ... 14 more
> 2014-09-11 08:11:04,991 WARN [Codec20] (ForkThread-1,DistTopologyChangeUnderLoadTest) ISPN004005: Error received from the server: io.netty.handler.codec.DecoderException: org.infinispan.server.hotrod.HotRodException: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> {code}
> Cache stopping/stopped should have a different error code too so that clients can handle it properly.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-3743) Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3743?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3743:
-----------------------------------------------
Matej Čimbora <mcimbora(a)redhat.com> changed the Status of [bug 1039090|https://bugzilla.redhat.com/show_bug.cgi?id=1039090] from ON_QA to VERIFIED
> Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions
> --------------------------------------------------------------------------------
>
> Key: ISPN-3743
> URL: https://issues.jboss.org/browse/ISPN-3743
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
>
> When a cache in STOPPING state receives a command, the exception is propagated all the way to the caller:
> {noformat}
> 09:33:02,005 ERROR (testng-NonTxPutIfAbsentDuringLeaveStressTest:) [UnitTestTestNGListener] Test testNodeLeavingDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest) failed.
> java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeD-57301, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:93)
> {noformat}
> This causes random failures in NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent.
> The originator should either ignore the IllegalStateException or wait for a new cache topology and retry the operation, just like it should for SuspectExceptions (ISPN-2577).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months
[JBoss JIRA] (ISPN-4908) Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4908?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4908:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1176021|https://bugzilla.redhat.com/show_bug.cgi?id=1176021] from ON_QA to VERIFIED
> Clustered cache with unshared store is inconsistent after restarting one node if entries are deleted during restart
> -------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-4908
> URL: https://issues.jboss.org/browse/ISPN-4908
> Project: Infinispan
> Issue Type: Bug
> Environment: Clustered REPL cache, preloaded, no eviction/expiration
> Reporter: Wolf-Dieter Fink
> Assignee: William Burns
>
> If a cache instance with an unshared cache store is down and the cache is changed until the instance is back and join the cluster the cache can become inconsisstent.
> If entries are deleted during downtime,
> - the with stale object is loaded first if preload=true
> - the local entries are updated with new and changed objects from the cluster
> - removed entries from the cluster are not seen and therefore not deleted
> After complete sync (only) this instance will have stale objects.
> From a consistence and performance perspective the store should be pruned on cluster-join by default in this case
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 2 months