[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 updated ISPN-3918:
-------------------------------
Attachment: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz
> 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, 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)
8 years, 8 months
[JBoss JIRA] (ISPN-6451) NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent still fails randomly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6451?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6451:
------------------------------------
I was wrong in my previous comment, the failures are both an instance of ISPN-3918. The first failure happens when a putIfAbsent(k, v1) command is retried after already writing a value to a backup owner, and the retry fails because another command has already written k=v2 on the primary. In another thread putIfAbsent fails and returns the correct value v2, but immediately afterwards get(k) returns v1 (the value on the backup).
> NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent still fails randomly
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-6451
> URL: https://issues.jboss.org/browse/ISPN-6451
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.2.0.Final, 9.1.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 8.2.5.Final, 9.0.0.Alpha3
>
>
> {noformat}
> java.util.concurrent.ExecutionException: java.lang.AssertionError: expected:<value_48_1> but was:<null>
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at java.util.concurrent.FutureTask.get(FutureTask.java:206)
> at org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent(NonTxPutIfAbsentDuringLeaveStressTest.java:97)
> 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.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:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.AssertionError: expected:<value_48_1> 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.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest$1.doPut(NonTxPutIfAbsentDuringLeaveStressTest.java:82)
> at org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest$1.call(NonTxPutIfAbsentDuringLeaveStressTest.java:66)
> at org.infinispan.test.AbstractInfinispanTest$LoggingCallable.call(AbstractInfinispanTest.java:478)
> ... 4 more
> {noformat}
> http://ci.infinispan.org/project.html?projectId=Infinispan&testNameId=717...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 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:
------------------------------------
The situation is even worse when the topology changes: a {{get}} after a failed {{putIfAbsent}} can return not only {{null}}, but also a completely different value.
Say {{owners(k) = AB}}, and there is a topology change but the owners of {{k}} stay the same. In the following scenario, thread _B-app3_ first sees {{putIfAbsent(k, v3) = v2}}, and then {{get(k) = v1}} (_B-appX_ means application thread X on B, and _A-remoteX_ means remote thread X on A):
# _B-app1_: start putIfAbsent(k, v1)
# _B-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
# _B-remote1_: receive backup request for putIfAbsent(k, v1)
# _B-remote1_: write k=v1
# _B-remote1_: send backup ack for putIfAbsent(k, v1)
# _A-remote1_: check topology, send OutdatedTopologyException back to B
# _A-app2_: start putIfAbsent(k, v2)
# _A-app2_: send backup request for putIfAbsent(k, v2) to B
# _A-app2_: write k=v2
# _B-app3_: start putIfAbsent(k, v3)
# _B-app3_: send putIfAbsent(k, v3) to A (primary)
# _A-remote3_: receive putIfAbsent(k, v3)
# _A-remote3_: read v2 from data container, fail the command
# _B-remote3_: receive v2 for putIfAbsent(k, v3)
# *_B-app3_: return v2 for putIfAbsent(k, v3) (put was unsuccessful)*
# _B-app3_: start get(k)
# _B-app3_: read v1 from local container
# *_B-app3_: return v1 for get(k)*
# _B-remote2_: receive putIfAbsent(k, v2) backup command
# _B-remote2_: write k=v2
# _B-remote2_: send backup ack for putIfAbsent(k, v2)
# _A-remote2_: receive backup ack for putIfAbsent(k, v2)
# *_A-app2_: return null for putIfAbsent(k, v2) (put was successful)*
# _B-remote1_: receive OutdatedTopologyException for putIfAbsent(k, v1)
# _B-remote1_: retry, send putIfAbsent(k, v1) to A (primary)
# _A-remote1_: receive putIfAbsent(k, v1)
# _A-remote1_: read v2 from data container, fail the command
# _B-remote1_: receive v2 for putIfAbsent(k, v1)
# *_B-app1_: return v2 for putIfAbsent(k, v1) (put was unsuccessful)*
> 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: 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)
8 years, 8 months
[JBoss JIRA] (ISPN-8189) SizeCommand unnecessarily unmarshalls keys to count
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-8189:
-------------------------------------
Summary: SizeCommand unnecessarily unmarshalls keys to count
Key: ISPN-8189
URL: https://issues.jboss.org/browse/ISPN-8189
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.1.0.Final
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 9.1.1.Final
The SizeCommand uses cache.keySet().stream().count() to count keys, but if the cache is using binary storage, this unmarshalls each key.
Using the identityencoder allows us to make this operation much cheaper.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ISPN-8188) StateTransferLargeObjectTest random failures
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-8188:
---------------------------------------
Summary: StateTransferLargeObjectTest random failures
Key: ISPN-8188
URL: https://issues.jboss.org/browse/ISPN-8188
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 9.1.0.Final
Reporter: Gustavo Fernandes
{noformat}
[ERROR] testForFailure(org.infinispan.statetransfer.StateTransferLargeObjectTest) Time elapsed: 0.314 s <<< FAILURE!
org.infinispan.commons.CacheException: java.lang.IllegalStateException
at org.infinispan.interceptors.impl.InvocationContextInterceptor.rethrowException(InvocationContextInterceptor.java:144)
at org.infinispan.interceptors.impl.InvocationContextInterceptor.access$000(InvocationContextInterceptor.java:44)
at org.infinispan.interceptors.impl.InvocationContextInterceptor$1.apply(InvocationContextInterceptor.java:61)
at org.infinispan.interceptors.InvocationExceptionFunction.apply(InvocationExceptionFunction.java:21)
at org.infinispan.interceptors.impl.SimpleAsyncInvocationStage.addCallback(SimpleAsyncInvocationStage.java:67)
at org.infinispan.interceptors.InvocationStage.andExceptionally(InvocationStage.java:34)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:132)
at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:97)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:60)
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50)
at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:248)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:501)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:494)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:348)
at org.infinispan.cache.impl.EncoderCache.get(EncoderCache.java:631)
at org.infinispan.statetransfer.StateTransferLargeObjectTest.testForFailure(StateTransferLargeObjectTest.java:76)
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:498)
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:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.remoteGet(BaseDistributionInterceptor.java:163)
at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:533)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleMissingEntryOnLocalRead(BaseDistributionInterceptor.java:858)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.onEntryMiss(BaseDistributionInterceptor.java:853)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetCommand(BaseDistributionInterceptor.java:848)
at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetKeyValueCommand(BaseDistributionInterceptor.java:865)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:102)
at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:217)
at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:205)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54)
at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitDataReadCommand(OptimisticLockingInterceptor.java:52)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:110)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.impl.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:374)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:41)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:189)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.updateAndInvokeNextRead(BaseStateTransferInterceptor.java:196)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.handleReadCommand(BaseStateTransferInterceptor.java:191)
at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.visitGetKeyValueCommand(BaseStateTransferInterceptor.java:174)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:58)
at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:94)
at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:83)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38)
at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:127)
... 32 more
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ISPN-8187) Random failures in Memcached testsuite due to port conflicts
by Gustavo Fernandes (JIRA)
Gustavo Fernandes created ISPN-8187:
---------------------------------------
Summary: Random failures in Memcached testsuite due to port conflicts
Key: ISPN-8187
URL: https://issues.jboss.org/browse/ISPN-8187
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.1.0.Final
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
{noformat}
[ERROR] testStoreAsBinaryOverride(org.infinispan.server.memcached.MemcachedFunctionalTest) Time elapsed: 0.028 s <<< FAILURE!
io.netty.channel.unix.Errors$NativeIoException: bind(..) failed: Address already in use
at io.netty.channel.unix.Errors.newIOException(Errors.java:117)
at io.netty.channel.unix.Socket.bind(Socket.java:234)
at io.netty.channel.epoll.EpollServerSocketChannel.doBind(EpollServerSocketChannel.java:91)
at io.netty.channel.AbstractChannel$AbstractUnsafe.bind(AbstractChannel.java:554)
at io.netty.channel.DefaultChannelPipeline$HeadContext.bind(DefaultChannelPipeline.java:1258)
at io.netty.channel.AbstractChannelHandlerContext.invokeBind(AbstractChannelHandlerContext.java:501)
at io.netty.channel.AbstractChannelHandlerContext.bind(AbstractChannelHandlerContext.java:486)
at io.netty.channel.DefaultChannelPipeline.bind(DefaultChannelPipeline.java:980)
at io.netty.channel.AbstractChannel.bind(AbstractChannel.java:250)
at io.netty.bootstrap.AbstractBootstrap$2.run(AbstractBootstrap.java:365)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
at io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
at java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (ISPN-8175) LocalCacheStateTransferTest random failures
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-8175?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes updated ISPN-8175:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> LocalCacheStateTransferTest random failures
> -------------------------------------------
>
> Key: ISPN-8175
> URL: https://issues.jboss.org/browse/ISPN-8175
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Gustavo Fernandes
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
>
> {noformat}
> [ERROR] testStateTransferWithClusterIdle(org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest) Time elapsed: 0.698 s <<< FAILURE!
> java.lang.AssertionError:
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41)
> at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.assertNoStateTransferInReceivingSite(LocalCacheStateTransferTest.java:147)
> at org.infinispan.xsite.statetransfer.LocalCacheStateTransferTest.testStateTransferWithClusterIdle(LocalCacheStateTransferTest.java:96)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months