October 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8627) Add CacheContainerAdmin.getOrCreateCache() method

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8627?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8627: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.0.Final) > Add CacheContainerAdmin.getOrCreateCache() method > ------------------------------------------------- > > Key: ISPN-8627 > URL: https://issues.jboss.org/browse/ISPN-8627 > Project: Infinispan > Issue Type: Bug > Components: Core, Hot Rod > Affects Versions: 9.2.0.Beta1 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.1.Final > > > CacheContainerAdmin has a createCache method which fails if the cache already exists. To make the life of developers easier, it should also have a getOrCreateCache() which returns an existing cache if possible. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8643) ClientConnectionPoolingTest.testMaxActiveReached random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8643?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8643: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.0.Final) > ClientConnectionPoolingTest.testMaxActiveReached random failures > ---------------------------------------------------------------- > > Key: ISPN-8643 > URL: https://issues.jboss.org/browse/ISPN-8643 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 9.2.0.Beta2 > Reporter: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.1.Final > > > Looks like waiting for 1s for all the connections to be releases is not enough: > {noformat} > java.lang.AssertionError: > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:229) > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:211) > at org.infinispan.test.AbstractInfinispanTest.eventually(AbstractInfinispanTest.java:187) > at org.infinispan.client.hotrod.ClientConnectionPoolingTest.testMaxActiveReached(ClientConnectionPoolingTest.java:208) > 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) > {noformat} > http://ci.infinispan.org/job/Infinispan/job/master/336 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8513) DistSyncOnePhaseTxStateTransferTest random failures

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8513?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8513: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.0.Final) > DistSyncOnePhaseTxStateTransferTest random failures > --------------------------------------------------- > > Key: ISPN-8513 > URL: https://issues.jboss.org/browse/ISPN-8513 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core > Affects Versions: 9.2.0.Alpha2 > Reporter: Pedro Ruivo > Assignee: Dan Berindei > Priority: Major > Labels: testsuite_stability > Fix For: 10.0.1.Final > > Attachments: DistSyncOnePhaseTxStateTransferTest_pr_wburns_offheap_singlenode2_20171030.log.gz > > > {{DistSyncOnePhaseTxStateTransferTest}} sometimes asserts that the x-site transfer has finished in the remote site too early: > {noformat} > 17:34:38,464 ERROR (testng-Test:[]) [TestSuiteProgress] Test failed: org.infinispan.xsite.statetransfer.DistSyncOnePhaseTxStateTransferTest.testCancelStateTransfer[null, tx=false] > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:41) ~[testng-6.8.8.jar:?] > at org.testng.AssertJUnit.assertFalse(AssertJUnit.java:49) ~[testng-6.8.8.jar:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest$20.assertInCache(BaseStateTransferTest.java:601) ~[test-classes/:?] > at org.infinispan.xsite.AbstractXSiteTest.assertInSite(AbstractXSiteTest.java:172) ~[test-classes/:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest.assertNoStateTransferInReceivingSite(BaseStateTransferTest.java:596) ~[test-classes/:?] > at org.infinispan.xsite.statetransfer.BaseStateTransferTest.testCancelStateTransfer(BaseStateTransferTest.java:141) ~[test-classes/:?] > {noformat} > In fact, this part of the test seems to let the state transfer finish normally instead of cancelling it, so it could use some logs/comments to explain what's going on. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9031) Add CodedInputStream.setsize functionality

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9031?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9031: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.0.Final) > Add CodedInputStream.setsize functionality > ------------------------------------------ > > Key: ISPN-9031 > URL: https://issues.jboss.org/browse/ISPN-9031 > Project: Infinispan > Issue Type: Feature Request > Reporter: Lena Herrmann > Priority: Major > Fix For: 10.0.1.Final > > > If you want to use the Protobufmarchaller for larger objects the following exception occurs: > {code:java} > at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:49) > at org.infinispan.client.hotrod.impl.protocol.CodecUtils.readUnmarshallByteArray(CodecUtils.java:38) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readUnmarshallByteArray(Codec20.java:54) > at org.infinispan.client.hotrod.impl.operations.GetOperation.executeOperation(GetOperation.java:36) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.get(RemoteCacheImpl.java:367) > at com.channelpilot.api.tabledata.RemoteCacheConnector.get(RemoteCacheConnector.java:49) > at com.channelpilot.api.tabledata.TableDataService.get(TableDataService.java:91) > at com.channelpilot.api.tabledata.build.ControlDataBuilder.build(ControlDataBuilder.java:48) > at com.channelpilot.api.frontend.jobs.threads.BuildTableDataJob.execute(BuildTableDataJob.java:72) > at com.channelpilot.api.frontend.jobs.threads.BuildTableDataJob.execute(BuildTableDataJob.java:31) > at com.channelpilot.utils.concurrent.CPCallable.call(CPCallable.java:105) > 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: protostream.com.google.protobuf.InvalidProtocolBufferException: Protocol message was too large. May be malicious. Use CodedInputStream.setSizeLimit() to increase the size limit. > at protostream.com.google.protobuf.InvalidProtocolBufferException.sizeLimitExceeded(InvalidProtocolBufferException.java:122) > at protostream.com.google.protobuf.CodedInputStream.readRawBytesSlowPath(CodedInputStream.java:1166) > at protostream.com.google.protobuf.CodedInputStream.readByteArray(CodedInputStream.java:535) > at org.infinispan.protostream.impl.RawProtoStreamReaderImpl.readByteArray(RawProtoStreamReaderImpl.java:105) > at org.infinispan.protostream.WrappedMessage.readMessage(WrappedMessage.java:232) > at org.infinispan.protostream.ProtobufUtil.fromWrappedByteArray(ProtobufUtil.java:122) > at org.infinispan.query.remote.client.BaseProtoStreamMarshaller.objectFromByteBuffer(BaseProtoStreamMarshaller.java:32) > at org.infinispan.commons.marshall.AbstractMarshaller.objectFromByteBuffer(AbstractMarshaller.java:82) > at org.infinispan.client.hotrod.marshall.MarshallerUtil.bytes2obj(MarshallerUtil.java:33) > {code} > According to the official protobuf-documentation one should increase the size-limit, if this exception is thrown. Within infinispan there is no possibility to change this size in some way. > Adding the to for example a configurationbuilder or similar, would be a good improvement. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9112?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9112: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.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 > Priority: Major > Fix For: 10.0.1.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.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9101?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9101: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.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: 10.0.1.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.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9319) Cache.lock(key) should throw AvailabilityException in degraded mode

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9319?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9319: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.0.Final) > Cache.lock(key) should throw AvailabilityException in degraded mode > ------------------------------------------------------------------- > > Key: ISPN-9319 > URL: https://issues.jboss.org/browse/ISPN-9319 > Project: Infinispan > Issue Type: Bug > Components: Core, Test Suite - Core > Affects Versions: 9.3.0.CR1 > Reporter: Dan Berindei > Priority: Major > Fix For: 10.0.1.Final > > > We need a test for {{cache.lock(key)}} when one of the owners is not an actual member of the cluster and the cache is in degraded mode. {{PartitionHandlingInterceptor}} doesn't handle {{LockControlCommand}} explicitly, so it might end up throwing {{TimeoutException}} after waiting for a new topology. We should make sure it throws an {{AvailabilityException}} instead. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9079?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9079: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.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 > Priority: Major > Fix For: 10.0.1.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.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9177?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9177: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.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 > Priority: Major > Fix For: 10.0.1.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.13.8#713008)

6 years, 5 months

1
0
0 / 0

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

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9252?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9252: ---------------------------------- Fix Version/s: 10.0.1.Final (was: 10.0.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 > Priority: Major > Fix For: 10.0.1.Final > > > NettyTransportConnectionStats should have an easier way to get statistics rather than going over JMX itself. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 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 October 2019