[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)
6 years, 6 months
[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}
> [0m[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)
6 years, 6 months
[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)
6 years, 6 months
[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)
6 years, 6 months
[JBoss JIRA] (ISPN-9175) Mark Hibernate 2LC tests unstable
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9175?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9175:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> Mark Hibernate 2LC tests unstable
> ---------------------------------
>
> Key: ISPN-9175
> URL: https://issues.jboss.org/browse/ISPN-9175
> Project: Infinispan
> Issue Type: Task
> Components: Hibernate Cache
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 9.4.0.Final
>
>
> Recent known failures:
> 1. Spotted in PR for ISPN-8601 but probably not related to that JIRA:
> {code}
> EntityRegionAccessStrategyTest.testUpdate[JTA, REPL_SYNC,AccessType[read-write]]
> EntityRegionAccessStrategyTest.testRemoveAll[JTA, REPL_SYNC, AccessType[read-only]]
> {code}
> 2. Unclear when the first time it happened:
> {code}EntityCollectionInvalidationTest.testAll[read-write, DIST_SYNC]{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (ISPN-9173) Availability mode should be updated atomically with the actual members
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-9173?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño updated ISPN-9173:
-----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.3.0.Final)
> Availability mode should be updated atomically with the actual members
> ----------------------------------------------------------------------
>
> Key: ISPN-9173
> URL: https://issues.jboss.org/browse/ISPN-9173
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Labels: testsuite_stability
> Fix For: 9.4.0.Final
>
>
> This is a follow-up on ISPN-7682, which asks for the topology itself to be updated atomically.
> {{LocalTopologyManagerImpl}} has additional logic to update the availability mode first when the cache becomes degraded and to update it last when the cache becomes available, which means any delay between the updates cannot cause data inconsistencies.
> But that logic doesn't really belong in {{LocalTopologyManagerImpl}}, and it's easy to forget it's there (and in fact we had a bug there related to the new rebalance phases).
> In addition, tests that want to check the cache behaviour in degraded mode and wait only for the availability mode change will fail if there's a big delay between the availability mode change. I actually hit this while testing my ISPN-8731/ISPN-7682 changes, and I had added a random delay in {{StateConsumerImpl}} before {{distributionManager.setCacheTopology()}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months