January 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8742) DistSyncTxL1FuncTest.testGetBlockingAnotherGetCacheEntry random failures

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-8742?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-8742: ------------------------------- Status: Open (was: New) > DistSyncTxL1FuncTest.testGetBlockingAnotherGetCacheEntry random failures > ------------------------------------------------------------------------ > > Key: ISPN-8742 > URL: https://issues.jboss.org/browse/ISPN-8742 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.2.0.CR2 > > > getAsync() doesn't always run interceptor callbacks on a separate thread. > The remote get can finish before the calling thread calls thenAccept(), > especially when the test suite is limited to a single CPU. > When that happens, the test thread cannot unblock the callback and the operation eventually times out: > {noformat} > 17:58:40,510 TRACE (jgroups-7,Test-NodeA-4165:[]) [JGroupsTransport] Test-NodeA-4165 received response for request 15 from Test-NodeC-55903: SuccessfulResponse(MetadataImmortalCacheValue {value=first-put, metadata=EmbeddedExpirableMetadata{lifespan=-1, maxIdle=-1, version=SimpleClusteredVersion{topologyId=13, version=1}}}) > 17:58:40,511 TRACE (testng-Test:[]) [CheckPoint] Triggering event pre_acquire_shared_topology_lock_invoked * 1 (available = 1, total = 1) > 17:58:40,511 TRACE (testng-Test:[]) [CheckPoint] Waiting for event pre_acquire_shared_topology_lock_released * 1 > 17:58:50,511 ERROR (testng-Test:[]) [CheckPoint] Timed out waiting for event pre_acquire_shared_topology_lock_released * 1 (available = 0, total = 0 > 17:58:50,512 ERROR (testng-Test:[]) [InvocationContextInterceptor] ISPN000136: Error executing command GetKeyValueCommand, writing keys [] > java.util.concurrent.TimeoutException: Timed out waiting for event pre_acquire_shared_topology_lock_released > at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:44) ~[test-classes/:?] > at org.infinispan.test.fwk.CheckPoint.awaitStrict(CheckPoint.java:34) ~[test-classes/:?] > at org.infinispan.distribution.BaseDistSyncL1Test.lambda$waitUntilAboutToAcquireLock$20(BaseDistSyncL1Test.java:554) ~[test-classes/:?] > at org.mockito.internal.stubbing.StubbedInvocationMatcher.answer(StubbedInvocationMatcher.java:35) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.handler.MockHandlerImpl.handle(MockHandlerImpl.java:95) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.handler.NullResultGuardian.handle(NullResultGuardian.java:32) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.handler.InvocationNotifierHandler.handle(InvocationNotifierHandler.java:36) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:57) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor.doIntercept(MockMethodInterceptor.java:43) ~[mockito-core-2.7.21.jar:?] > at org.mockito.internal.creation.bytebuddy.MockMethodInterceptor$DispatcherDefaultingToRealMethod.interceptAbstract(MockMethodInterceptor.java:137) ~[mockito-core-2.7.21.jar:?] > at org.infinispan.statetransfer.StateTransferLock$MockitoMock$827961965.acquireSharedTopologyLock(Unknown Source) ~[classes/:?] > at org.infinispan.interceptors.distribution.L1WriteSynchronizer.runL1UpdateIfPossible(L1WriteSynchronizer.java:176) ~[classes/:?] > at org.infinispan.distribution.impl.L1ManagerImpl.remoteValueFound(L1ManagerImpl.java:196) ~[classes/:?] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.lambda$remoteGet$1(BaseDistributionInterceptor.java:197) ~[classes/:?] > at java.util.concurrent.CompletableFuture.uniAccept(CompletableFuture.java:656) ~[?:1.8.0_152] > at java.util.concurrent.CompletableFuture.uniAcceptStage(CompletableFuture.java:669) ~[?:1.8.0_152] > at java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:1997) ~[?:1.8.0_152] > at java.util.concurrent.CompletableFuture.thenAccept(CompletableFuture.java:110) ~[?:1.8.0_152] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.remoteGet(BaseDistributionInterceptor.java:184) ~[classes/:?] > at org.infinispan.interceptors.distribution.TxDistributionInterceptor.remoteGet(TxDistributionInterceptor.java:553) ~[classes/:?] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.handleMissingEntryOnLocalRead(BaseDistributionInterceptor.java:796) ~[classes/:?] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.onEntryMiss(BaseDistributionInterceptor.java:791) ~[classes/:?] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetCommand(BaseDistributionInterceptor.java:786) ~[classes/:?] > at org.infinispan.interceptors.distribution.BaseDistributionInterceptor.visitGetKeyValueCommand(BaseDistributionInterceptor.java:803) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndFinally(BaseAsyncInterceptor.java:150) ~[classes/:?] > at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performL1Lookup(L1NonTxInterceptor.java:155) ~[classes/:?] > at org.infinispan.interceptors.distribution.L1NonTxInterceptor.performCommandWithL1WriteIfAble(L1NonTxInterceptor.java:130) ~[classes/:?] > at org.infinispan.interceptors.distribution.L1NonTxInterceptor.visitDataReadCommand(L1NonTxInterceptor.java:121) ~[classes/:?] > at org.infinispan.interceptors.distribution.L1NonTxInterceptor.visitGetKeyValueCommand(L1NonTxInterceptor.java:110) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextThenAccept(BaseAsyncInterceptor.java:98) ~[classes/:?] > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitDataReadCommand(EntryWrappingInterceptor.java:201) ~[classes/:?] > at org.infinispan.interceptors.impl.EntryWrappingInterceptor.visitGetKeyValueCommand(EntryWrappingInterceptor.java:189) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.locking.OptimisticLockingInterceptor.visitDataReadCommand(OptimisticLockingInterceptor.java:53) ~[classes/:?] > at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:105) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.impl.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:360) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitCommand(TransactionSynchronizerInterceptor.java:41) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndHandle(BaseAsyncInterceptor.java:185) ~[classes/:?] > at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.handleReadCommand(BaseStateTransferInterceptor.java:187) ~[classes/:?] > at org.infinispan.interceptors.impl.BaseStateTransferInterceptor.visitGetKeyValueCommand(BaseStateTransferInterceptor.java:170) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) ~[classes/:?] > at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitDataReadCommand(CacheMgmtInterceptor.java:103) ~[classes/:?] > at org.infinispan.interceptors.impl.CacheMgmtInterceptor.visitGetKeyValueCommand(CacheMgmtInterceptor.java:92) ~[classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) ~[classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNextAndExceptionally(BaseAsyncInterceptor.java:123) [classes/:?] > at org.infinispan.interceptors.impl.InvocationContextInterceptor.visitCommand(InvocationContextInterceptor.java:90) [classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:56) [classes/:?] > at org.infinispan.interceptors.impl.BatchingInterceptor.handleDefault(BatchingInterceptor.java:53) [classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106) [classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) [classes/:?] > at org.infinispan.interceptors.BaseAsyncInterceptor.invokeNext(BaseAsyncInterceptor.java:54) [classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.handleDefault(DDAsyncInterceptor.java:54) [classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitGetKeyValueCommand(DDAsyncInterceptor.java:106) [classes/:?] > at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:38) [classes/:?] > at org.infinispan.interceptors.DDAsyncInterceptor.visitCommand(DDAsyncInterceptor.java:50) [classes/:?] > at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invokeAsync(AsyncInterceptorChainImpl.java:234) [classes/:?] > at org.infinispan.cache.impl.CacheImpl.getAsync(CacheImpl.java:1591) [classes/:?] > at org.infinispan.cache.impl.CacheImpl.getAsync(CacheImpl.java:1584) [classes/:?] > at org.infinispan.cache.impl.AbstractDelegatingCache.getAsync(AbstractDelegatingCache.java:467) [classes/:?] > at org.infinispan.cache.impl.EncoderCache.getAsync(EncoderCache.java:915) [classes/:?] > at org.infinispan.distribution.BaseDistSyncL1Test.testGetBlockingAnotherGetCacheEntry(BaseDistSyncL1Test.java:515) [test-classes/:?] > {noformat} > The lingering {{L1WriteSynchronizer}} also fails the next test (usually {{testGetBlockingAnotherGetWithMiss}}). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8741) ClusteredLockSplitBrainTest fails randomly

by Katia Aresti (JIRA)

Katia Aresti created ISPN-8741: ---------------------------------- Summary: ClusteredLockSplitBrainTest fails randomly Key: ISPN-8741 URL: https://issues.jboss.org/browse/ISPN-8741 Project: Infinispan Issue Type: Bug Components: Clustered Locks Affects Versions: 9.2.0.CR1 Reporter: Katia Aresti Assignee: Katia Aresti -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8740) Refactor backup-write commands (triangle)

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8740?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-8740: ----------------------------------- I prefer to decouple backup commands from regular commands, that's why I've suggested to link them through helpers rather than adding extra methods to interfaces. These helpers also keep all the lambdas together, so once you start passing > 3 parameters ([like here|https://github.com/infinispan/infinispan/commit/74f4c8962cfad0e406e1...]) it makes passing these more compact. Not that it would be applicable everywhere. > Refactor backup-write commands (triangle) > ----------------------------------------- > > Key: ISPN-8740 > URL: https://issues.jboss.org/browse/ISPN-8740 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > h2. Split the backup commands > * single key > * single key, functional > * put map > * entries functional > * keys functional > h2. Remove method from {{WriteCommand}} interface (Radim's suggestion) > * Use helper methods to create the backup-write commands. (note. I'm not sure if it makes much sense) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8740) Refactor backup-write commands (triangle)

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-8740?page=com.atlassian.jira.plugin.... ] Radim Vansa edited comment on ISPN-8740 at 1/31/18 9:46 AM: ------------------------------------------------------------ I prefer to decouple backup commands from regular commands, that's why I've suggested to link them through helpers rather than adding extra methods to interfaces. These helpers also keep all the lambdas together, so once you start passing >= 3 parameters ([like here|https://github.com/infinispan/infinispan/commit/74f4c8962cfad0e406e1...]) it makes passing these more compact. Not that it would be applicable everywhere. was (Author: rvansa): I prefer to decouple backup commands from regular commands, that's why I've suggested to link them through helpers rather than adding extra methods to interfaces. These helpers also keep all the lambdas together, so once you start passing > 3 parameters ([like here|https://github.com/infinispan/infinispan/commit/74f4c8962cfad0e406e1...]) it makes passing these more compact. Not that it would be applicable everywhere. > Refactor backup-write commands (triangle) > ----------------------------------------- > > Key: ISPN-8740 > URL: https://issues.jboss.org/browse/ISPN-8740 > Project: Infinispan > Issue Type: Enhancement > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > > h2. Split the backup commands > * single key > * single key, functional > * put map > * entries functional > * keys functional > h2. Remove method from {{WriteCommand}} interface (Radim's suggestion) > * Use helper methods to create the backup-write commands. (note. I'm not sure if it makes much sense) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8580) Refactor ThreadLocal use to handle hotrod flags

by Katia Aresti (JIRA)

[ https://issues.jboss.org/browse/ISPN-8580?page=com.atlassian.jira.plugin.... ] Katia Aresti updated ISPN-8580: ------------------------------- Summary: Refactor ThreadLocal use to handle hotrod flags (was: Reactor ThreadLocal use to handle hotrod flags ) > Refactor ThreadLocal use to handle hotrod flags > ------------------------------------------------- > > Key: ISPN-8580 > URL: https://issues.jboss.org/browse/ISPN-8580 > Project: Infinispan > Issue Type: Task > Components: Hot Rod > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Optional > > OperationsFactory and MultimapOperationsFactory use ThreadLocal to share flags. > Instead store the flags on each instance of the RemoteMultiMap/RemoteCache and pass them when they invoke something. When a new flag is added or removed we would create a new instance. This seems much more intuitive to me and simpler. > Then the flags can be defaulted on the RemoteCache/RemoteMultiMap when it is retrieved from the manager as well. > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8740) Refactor backup-write commands (triangle)

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-8740: --------------------------------- Summary: Refactor backup-write commands (triangle) Key: ISPN-8740 URL: https://issues.jboss.org/browse/ISPN-8740 Project: Infinispan Issue Type: Enhancement Reporter: Pedro Ruivo Assignee: Pedro Ruivo h2. Split the backup commands * single key * single key, functional * put map * entries functional * keys functional h2. Remove method from {{WriteCommand}} interface (Radim's suggestion) * Use helper methods to create the backup-write commands. (note. I'm not sure if it makes much sense) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8738) InfinispanExtensionIT fails due to xpp3 ModuleLoadException

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8738?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8738: ------------------------------------ Status: Open (was: New) > InfinispanExtensionIT fails due to xpp3 ModuleLoadException > ----------------------------------------------------------- > > Key: ISPN-8738 > URL: https://issues.jboss.org/browse/ISPN-8738 > Project: Infinispan > Issue Type: Bug > Components: WildFly modules > Affects Versions: 9.2.0.CR1 > Reporter: Ryan Emerson > Assignee: Gustavo Fernandes > > ISPN-8427 introduced the XStreamException which depends on xpp3, this is defined as a dependency on the xstream module, however the xpp3 module is never defined. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8739) Lower verbosity of diagnostic messages

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-8739: ----------------------------------------- Summary: Lower verbosity of diagnostic messages Key: ISPN-8739 URL: https://issues.jboss.org/browse/ISPN-8739 Project: Infinispan Issue Type: Enhancement Components: Cloud Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8739) Lower verbosity of diagnostic messages

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-8739?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-8739: -------------------------------------- Sprint: Sprint #8 Jan 29th - Feb 16th > Lower verbosity of diagnostic messages > -------------------------------------- > > Key: ISPN-8739 > URL: https://issues.jboss.org/browse/ISPN-8739 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7765) Allow HotRodDecoder to be shared between Netty pipelines

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7765?page=com.atlassian.jira.plugin.... ] Radim Vansa closed ISPN-7765. ----------------------------- Resolution: Rejected > Allow HotRodDecoder to be shared between Netty pipelines > -------------------------------------------------------- > > Key: ISPN-7765 > URL: https://issues.jboss.org/browse/ISPN-7765 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: William Burns > > Currently {{HotRodDecoder}} instance can not be shared between Netty pipelines as {{HotRodEncoder}}. Currently each pipeline creates its own instance by calling: > {code} > server.getDecoder() > {code} > in {{NettyChannelInitializer#initializeChannel}}. We could probably make it a bit more efficient (or limit allocation rate at least) if we allow sharing single instance between pipelines. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 January 2018