May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9018) SslTest.testClientAuth random failures

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9018?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9018: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > SslTest.testClientAuth random failures > -------------------------------------- > > Key: ISPN-9018 > URL: https://issues.jboss.org/browse/ISPN-9018 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Labels: testsuite_stability > Fix For: 9.3.0.CR1 > > > The test fails with a timeout exception. There is probably more, but before ISPN-9017 is fixed gathering logs is too difficult. > {noformat} > 09:34:03,524 DEBUG (testng-Test:[]) [ChannelFactory] Creating new channel pool for 127.0.0.1:12411 > 09:34:09,732 INFO (testng-Test:[]) [RemoteCacheManager] ISPN004021: Infinispan version: null > 09:34:13,823 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.SslTest.testClientAuth > org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: FaultTolerantPingOperation{(default), flags=0} timed out after 3000 ms > at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:50) ~[classes/:?] > at org.infinispan.client.hotrod.impl.Util.await(Util.java:25) ~[classes/:?] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:472) ~[classes/:?] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:736) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:312) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:201) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:195) ~[classes/:?] > at org.infinispan.client.hotrod.SslTest.initServerAndClient(SslTest.java:103) ~[test-classes/:?] > at org.infinispan.client.hotrod.SslTest.testClientAuth(SslTest.java:131) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9017) HotRod client thread names should include the test name

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9017?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9017: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > HotRod client thread names should include the test name > ------------------------------------------------------- > > Key: ISPN-9017 > URL: https://issues.jboss.org/browse/ISPN-9017 > Project: Infinispan > Issue Type: Task > Components: Hot Rod, Test Suite - Server > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Radim Vansa > Priority: Minor > Fix For: 9.3.0.CR1 > > > I wanted to obtain a trace log for a {{SslTest}} failure I'm seeing locally, but when I filter by test name all I get is this: > {noformat} > 09:34:03,524 DEBUG (testng-Test:[]) [ChannelFactory] Creating new channel pool for 127.0.0.1:12411 > 09:34:09,732 INFO (testng-Test:[]) [RemoteCacheManager] ISPN004021: Infinispan version: null > 09:34:13,823 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.client.hotrod.SslTest.testClientAuth > org.infinispan.client.hotrod.exceptions.TransportException: java.net.SocketTimeoutException: FaultTolerantPingOperation{(default), flags=0} timed out after 3000 ms > at org.infinispan.client.hotrod.impl.Util.rewrap(Util.java:50) ~[classes/:?] > at org.infinispan.client.hotrod.impl.Util.await(Util.java:25) ~[classes/:?] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.ping(RemoteCacheImpl.java:472) ~[classes/:?] > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.resolveCompatibility(RemoteCacheImpl.java:736) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.createRemoteCache(RemoteCacheManager.java:312) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:201) ~[classes/:?] > at org.infinispan.client.hotrod.RemoteCacheManager.getCache(RemoteCacheManager.java:195) ~[classes/:?] > at org.infinispan.client.hotrod.SslTest.initServerAndClient(SslTest.java:103) ~[test-classes/:?] > at org.infinispan.client.hotrod.SslTest.testClientAuth(SslTest.java:131) ~[test-classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9016) Component metadata serialization format changes depending on compiler

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9016?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9016: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > Component metadata serialization format changes depending on compiler > --------------------------------------------------------------------- > > Key: ISPN-9016 > URL: https://issues.jboss.org/browse/ISPN-9016 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Priority: Minor > Fix For: 9.3.0.CR1 > > > The field and method metadata classes have a {{serialVersionUUID}}, but {{ComponentMetadata}} itself doesn't have it, so it can change at any time. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9008) RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9008?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9008: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > RpcManager.invokeCommandOnAll ignores cache member that are not in the cluster view > ----------------------------------------------------------------------------------- > > Key: ISPN-9008 > URL: https://issues.jboss.org/browse/ISPN-9008 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.1.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 9.3.0.CR1 > > > {{RpcManager.invokeCommandOnAll}} broadcasts the command to all the members of the JGroups cluster view, and the {{ResponseCollector}} is not notified if any members of the cache are not in the cluster view. > This is a problem in replicated caches with partition handling enabled, because it means a write can succeed in a minority partition in the time interval between {{JGroupsTransport}} seeing the minority cluster view and {{DistributionManagerImpl}} installing the {{DEGRADED_MODE}} cache topology. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8852) StackOverflowError when requesting data in case cache is in degraded mode

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-8852?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-8852: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > StackOverflowError when requesting data in case cache is in degraded mode > ------------------------------------------------------------------------- > > Key: ISPN-8852 > URL: https://issues.jboss.org/browse/ISPN-8852 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.1.4.Final > Reporter: Michal Stehlik > Assignee: Ryan Emerson > Fix For: 9.3.0.CR1 > > Attachments: stackowerflow.log > > > Found StackOverflowError in logs when network was disconnected, caches are in degraded mode and system attempt to operate with cache Read & Update. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

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

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9128?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9128: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > 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.3.0.CR1 > > 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)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9127) Remote commands can access components before they are started

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9127?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9127: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > Remote commands can access components before they are started > ------------------------------------------------------------- > > Key: ISPN-9127 > URL: https://issues.jboss.org/browse/ISPN-9127 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.2.Final, 9.3.0.Alpha1 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 9.3.0.CR1 > > > {{PerCacheInboundInvocationHandler.handle()}} may be called before the component was started, because {{GlobalInboundInvocationHandler}} fetches it from the component registry without any checks. {{CommandsFactoryImpl.initializeReplicableCommand()}} doesn't wait for the components that it injects into remote commands to be started, either. > This started causing random test failures in {{ConcurrentStartForkChannelTest}} after ISPN-8515, which moved most initialization work from {{init()}} methods to {{start()}} methods. Because {{StateProviderImpl}} starts after {{StateTransferManagerImpl}}, it's possible for a node to receive a {{StateRequestCommand}} before {{StateProviderImpl}} has initialized: > {noformat} > 16:15:09,549 TRACE (remote-thread-Test-NodeB-p51957-t2:[org.infinispan.CONFIG]) [StateProviderImpl] Starting outbound transfer to node Test-NodeA for cache null, topology id 2, segments {0-255} > 16:15:09,551 WARN (remote-thread-Test-NodeB-p51957-t2:[]) [NonTotalOrderPerCacheInboundInvocationHandler] ISPN000071: Caught exception when handling command StateRequestCommand{cache=org.infinispan.CONFIG, origin=Test-NodeA, type=START_STATE_TRANSFER, topologyId=2, segments={0-255}} > java.lang.IllegalArgumentException: chunkSize must be greater than 0 > at org.infinispan.statetransfer.OutboundTransferTask.<init>(OutboundTransferTask.java:114) ~[classes/:?] > at org.infinispan.statetransfer.StateProviderImpl.startOutboundTransfer(StateProviderImpl.java:273) ~[classes/:?] > at org.infinispan.statetransfer.StateRequestCommand.invokeAsync(StateRequestCommand.java:101) ~[classes/:?] > at org.infinispan.remoting.inboundhandler.BasePerCacheInboundInvocationHandler.invokeCommand(BasePerCacheInboundInvocationHandler.java:94) ~[classes/:?] > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

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

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9112: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > 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.3.0.CR1 > > > {{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, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9111) Backup sites should be implicitly set on protobuf metadata cache configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9111?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9111: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > Backup sites should be implicitly set on protobuf metadata cache configuration > ------------------------------------------------------------------------------ > > Key: ISPN-9111 > URL: https://issues.jboss.org/browse/ISPN-9111 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 9.3.0.CR1, 9.3.0.Final > > > Given a cache manager, we should look for all enabled x-site locations and add those sites as SYNC backups for the protobuf metadata cache. Without this data, the user has to implement its own code to make sure the data is added in each site which is troublesome. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 5 months

1
0
0 / 0

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

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-9101?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic updated ISPN-9101: -------------------------------------- Fix Version/s: 9.3.0.CR1 (was: 9.3.0.Beta1) > 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.3.0.CR1 > > > {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)

6 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2018