June 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9128) RehashWithSharedStoreTest.testRehashes random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9128?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9128: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > RehashWithSharedStoreTest.testRehashes random failures > ------------------------------------------------------ > > Key: ISPN-9128 > URL: https://issues.jboss.org/browse/ISPN-9128 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.3.0.Alpha1 > Reporter: Dan Berindei > Assignee: Radim Vansa > Labels: testsuite_stability > Fix For: 9.4.0.Final > > Attachments: RehashWithSharedStoreTest_ISPN-7977_NPE_during_shutdown_20180507.log.gz > > > {noformat} > 16:00:32,748 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.distribution.rehash.RehashWithSharedStoreTest.testRehashes[SCATTERED_SYNC, tx=false, numOwners=1, l1=false] > java.lang.AssertionError: Should be able to see key on new owner > at org.infinispan.distribution.rehash.RehashWithSharedStoreTest.testRehashes(RehashWithSharedStoreTest.java:94) ~[test-classes/:?] > {noformat} > This first got my attention because I was working on ISPN-7977 and I noticed this NPE after the test failure: > {noformat} > 16:00:32,874 ERROR (jgroups-7,Test-NodeF-62673:[]) [ScatteredStateConsumerImpl] ISPN000471: Failed processing values received from remote node during rebalance. > java.lang.NullPointerException: null > at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.applyValues(ScatteredStateConsumerImpl.java:505) ~[classes/:?] > at org.infinispan.scattered.impl.ScatteredStateConsumerImpl.lambda$getValuesAndApply$8(ScatteredStateConsumerImpl.java:475) ~[classes/:?] > at java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:760) [?:1.8.0_152] > at java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:736) [?:1.8.0_152] > at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) [?:1.8.0_152] > at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) [?:1.8.0_152] > at org.infinispan.remoting.transport.AbstractRequest.complete(AbstractRequest.java:67) [classes/:?] > at org.infinispan.remoting.transport.impl.SingleTargetRequest.receiveResponse(SingleTargetRequest.java:57) [classes/:?] > at org.infinispan.remoting.transport.impl.SingleTargetRequest.onResponse(SingleTargetRequest.java:35) [classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9124) Uncaught exception in CounterConfigurationManager.startCounterCache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9124?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9124: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Uncaught exception in CounterConfigurationManager.startCounterCache > ------------------------------------------------------------------- > > Key: ISPN-9124 > URL: https://issues.jboss.org/browse/ISPN-9124 > Project: Infinispan > Issue Type: Task > Components: Test Suite - Core > Affects Versions: 9.2.2.Final > Reporter: Dan Berindei > Fix For: 9.4.0.Final > > > {{CounterConfigurationManager.startCounterCache}} starts the cache asynchronously, but a short test may stop the cache manager before the worker thread got to do anything. The worker thread doesn't catch the exception, so it's just logged on the console: > {noformat} > Exception in thread "async-thread--p132-t1" org.infinispan.IllegalLifecycleStateException: Cache container has been stopped and cannot be reused. Recreate the cache container. > at org.infinispan.manager.DefaultCacheManager.assertIsNotTerminated(DefaultCacheManager.java:951) > at org.infinispan.manager.DefaultCacheManager.internalGetCache(DefaultCacheManager.java:465) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:461) > at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:447) > at org.infinispan.counter.impl.manager.CounterConfigurationManager.lambda$startCounterCache$5(CounterConfigurationManager.java:230) > 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) > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9112) getCache() should not wait for the initial state transfer by default

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9112: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > getCache() should not wait for the initial state transfer by default > -------------------------------------------------------------------- > > Key: ISPN-9112 > URL: https://issues.jboss.org/browse/ISPN-9112 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.4.0.Final > > > {{DefaultCacheManager.getCache(name)}} normally blocks until the local node becomes a full member of the consistent hash and the rebalance has finished. This can cause problems when rebalancing is disabled, either explicitly by the administrator, or implicitly because the cache is in degraded mode. > Blocking can be disabled with {{builder.clustering().stateTransfer().awaitInitialTransfer(false)}} ({{await-initial-transfer="false"}} in XML}}, but we should make the non-blocking behaviour the default. We should also deprecate the method and attribute to enable the blocking behaviour, and instead add a method to {{AdvancedCache}} to wait for the initial state transfer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9101) EncryptProtocolIT.testEncryptProtocolRegistered random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9101?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9101: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > EncryptProtocolIT.testEncryptProtocolRegistered random failures > --------------------------------------------------------------- > > Key: ISPN-9101 > URL: https://issues.jboss.org/browse/ISPN-9101 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.4.0.Final > > > {noformat} > java.lang.RuntimeException: Could not retrieve HotRod host > at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63) > Caused by: java.lang.IllegalArgumentException: Could not retrieve attribute HostName on MBean jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport > at org.infinispan.server.test.security.jgroups.encrypt.EncryptProtocolIT.testEncryptProtocolRegistered(EncryptProtocolIT.java:63) > Caused by: javax.management.InstanceNotFoundException: jboss.datagrid-infinispan:type=Server,name=HotRod,component=Transport > {noformat} > The log shows this exception: > {noformat} > &amp#27;[0m&amp#27;[31m13:36:29,258 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.datagrid-jgroups.channel.cluster: org.jboss.msc.service.StartException in service jboss.datagrid-jgroups.channel.cluster: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format > at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:79) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1714) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1693) > at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1540) > at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35) > at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487) > at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.security.PrivilegedActionException: java.io.IOException: Invalid secret key format > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:623) > at org.infinispan.server.jgroups.JChannelFactory.createChannel(JChannelFactory.java:104) > at org.infinispan.server.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:77) > ... 8 more > Caused by: java.io.IOException: Invalid secret key format > at com.sun.crypto.provider.JceKeyStore.engineLoad(JceKeyStore.java:856) > at java.security.KeyStore.load(KeyStore.java:1445) > at org.jgroups.protocols.SYM_ENCRYPT.readSecretKeyFromKeystore(SYM_ENCRYPT.java:97) > at org.jgroups.protocols.SYM_ENCRYPT.init(SYM_ENCRYPT.java:78) > at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:840) > at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:479) > at org.jgroups.JChannel.init(JChannel.java:992) > at org.jgroups.JChannel.<init>(JChannel.java:148) > at org.infinispan.server.jgroups.JChannelFactory.lambda$createChannel$0(JChannelFactory.java:103) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:619) > ... 10 more > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9079) Cache operations during Conflict Resolution phase should force CR on that key

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9079?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9079: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Cache operations during Conflict Resolution phase should force CR on that key > ----------------------------------------------------------------------------- > > Key: ISPN-9079 > URL: https://issues.jboss.org/browse/ISPN-9079 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Fix For: 9.4.0.Final > > > During a partition merge conflict resolution can take a long time when there are many entries, therefore if a user initiates an operation on a key during this phase, it should force CR to occur on the key before executing the operation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9257) ClustertopologyManagerTest.testAbruptLeaveAfterGetStatus2[SCATTERED_SYNC, tx=false] random failures

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9257?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9257: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > ClustertopologyManagerTest.testAbruptLeaveAfterGetStatus2[SCATTERED_SYNC, tx=false] random failures > --------------------------------------------------------------------------------------------------- > > Key: ISPN-9257 > URL: https://issues.jboss.org/browse/ISPN-9257 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.3.0.CR1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Critical > Labels: testsuite_stability > Fix For: 9.4.0.Final > > Attachments: ISPN-8731_wrong_topology_2018-05-18_ClusterTopologyManagerTest-infinispan-core.log.gz > > > The test kills the coordinator NodeA, then while NodeB is trying to recover the caches it also kills NodeC. It expects NodeB to start a rebalance with 2 nodes and discards it, in order to test that it can process the 1-node rebalance first: > {noformat} > 00:34:06,582 DEBUG (transport-thread-test-NodeB-p12-t6:[testCache]) [ClusterTopologyManagerTest] Discarding rebalance command CacheTopology{id=8, phase=TRANSITORY, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=256, rebalanced=false, owners = (2)[test-NodeB-49590: 85, test-NodeC-58596: 85]}, pendingCH=ScatteredConsistentHash{ns=256, rebalanced=true, owners = (2)[test-NodeB-49590: 128, test-NodeC-58596: 128]}, unionCH=null, actualMembers=[test-NodeB-49590, test-NodeC-58596], persistentUUIDs=[6b96414e-15d8-4350-aa3c-4fb4fc34e888, d47dc4a9-2a95-4bb1-a83b-bb8a27c9999f]} > 00:34:06,609 DEBUG (transport-thread-test-NodeB-p12-t2:[Topology-testCache]) [LocalTopologyManagerImpl] Updating local topology for cache testCache: CacheTopology{id=9, phase=TRANSITORY, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=256, rebalanced=false, owners = (1)[test-NodeB-49590: 85]}, pendingCH=ScatteredConsistentHash{ns=256, rebalanced=false, owners = (1)[test-NodeB-49590: 128]}, unionCH=null, actualMembers=[test-NodeB-49590], persistentUUIDs=[6b96414e-15d8-4350-aa3c-4fb4fc34e888]} > 00:34:06,609 DEBUG (transport-thread-test-NodeB-p12-t2:[Topology-testCache]) [LocalTopologyManagerImpl] Installing fake cache topology CacheTopology{id=8, phase=NO_REBALANCE, rebalanceId=4, currentCH=ScatteredConsistentHash{ns=256, rebalanced=false, owners = (1)[test-NodeB-49590: 85]}, pendingCH=null, unionCH=null, actualMembers=[test-NodeB-49590], persistentUUIDs=[6b96414e-15d8-4350-aa3c-4fb4fc34e888]} for cache testCache > {noformat} > Unfortunately {{PreferAvailabilityStrategy}} has changed a bit and the rebalance ids don't always match the expectations of the test, so that the 1-node rebalance is discarded instead: > {noformat} > 09:46:10,530 DEBUG (transport-thread-Test-NodeB-p54539-t3:[testCache]) [Test] Discarding rebalance command CacheTopology{id=9, phase=TRANSITORY, rebalanceId=5, currentCH=ScatteredConsistentHash{ns=256, rebalanced=false, owners = (1)[Test-NodeB-62039: 85]}, pendingCH=ScatteredConsistentHash{ns=256, rebalanced=true, owners = (1)[Test-NodeB-62039: 256]}, unionCH=null, actualMembers=[Test-NodeB-62039], persistentUUIDs=[0ed7be74-4485-489b-baee-28c461c9e5de]} > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9254) Document Single Port

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9254?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9254: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Document Single Port > -------------------- > > Key: ISPN-9254 > URL: https://issues.jboss.org/browse/ISPN-9254 > Project: Infinispan > Issue Type: Task > Components: Remote Protocols > Reporter: Galder Zamarreño > Assignee: Sebastian Łaskawiec > Fix For: 9.4.0.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9252) Easier statistics collection in NettyTransportConnectionStats

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9252?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9252: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Easier statistics collection in NettyTransportConnectionStats > -------------------------------------------------------------- > > Key: ISPN-9252 > URL: https://issues.jboss.org/browse/ISPN-9252 > Project: Infinispan > Issue Type: Task > Components: Remote Protocols > Reporter: Galder Zamarreño > Fix For: 9.4.0.Final > > > NettyTransportConnectionStats should have an easier way to get statistics rather than going over JMX itself. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9191) ExceptionEvictionTest random failure during clearContent

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9191?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9191: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > ExceptionEvictionTest random failure during clearContent > -------------------------------------------------------- > > Key: ISPN-9191 > URL: https://issues.jboss.org/browse/ISPN-9191 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.Final > > > There is a random failure that occurs for ExceptionEvictionTest. > After each test is run we verify that there are no pending transactions leftover. It seems that the cause is due to the tx completion is sent asynchronously that we need to wait for them to clean up to verify. > This is related to https://issues.jboss.org/browse/ISPN-9189 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9177) Add RBAC to admin console pages

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9177?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9177: ----------------------------------- Fix Version/s: 9.4.0.Final (was: 9.3.0.Final) > Add RBAC to admin console pages > ------------------------------- > > Key: ISPN-9177 > URL: https://issues.jboss.org/browse/ISPN-9177 > Project: Infinispan > Issue Type: Feature Request > Components: Console > Affects Versions: 9.2.3.Final, 9.3.0.Beta1 > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Fix For: 9.4.0.Final > > > Up until now, we have assumed that admin user is able to invoke all operations, access and mutate all data from the admin console. With the advent of data manipulation capabilities in the console (ISPN-8759) and taking into account all existing management operations (some are destructive and irreversible), we should introduce RBAC to admin console page. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 9 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 June 2018