[JBoss JIRA] (ISPN-9124) Uncaught exception in CounterConfigurationManager.startCounterCache
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9124?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9124:
----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.4.0.CR3)
> 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, 6 months
[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: 9.4.0.Final
(was: 9.4.0.CR3)
> 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, 6 months
[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: 9.4.0.Final
(was: 9.4.0.CR3)
> 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)
7 years, 6 months
[JBoss JIRA] (ISPN-9072) Document Protobuf annotated collection null set callbacks
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9072?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9072:
----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.4.0.CR3)
> Document Protobuf annotated collection null set callbacks
> ---------------------------------------------------------
>
> Key: ISPN-9072
> URL: https://issues.jboss.org/browse/ISPN-9072
> Project: Infinispan
> Issue Type: Task
> Components: Documentation-Query
> Affects Versions: 9.2.1.Final
> Reporter: Galder Zamarreño
> Assignee: Adrian Nistor
> Fix For: 9.4.0.Final
>
>
> When using collection fields in Protobuf annotated classes, empty collections are marshalled into the same value as {{null}}, because Protobuf only has repeated fields and no fields is represented as {{null}}.
> This means that if you have an entity with an empty collection, when it's deserialized the collection will be null. This can be confusing for users and should be documented.
> [~anistor] had some ideas on how to improve this:
> {code}
> <anistor> I'm thinking of a way to make this easier for users that
> would prefer an empty collection being set instead of a
> null. would be possible by adding a new attribute for this in
> @ProtoField anotation
> > that'd be more predictable
> <anistor> would still not give you at deserializtion what was written
> during serialization. we do not have a null marker
> <anistor> it would just give you an empty collection if you prefer
> <anistor> instead of null
> > that option should be enabled by default
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9064) SiteManualSwitchTest.testManualClusterSwitch randomly fails
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9064?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9064:
----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.4.0.CR3)
> SiteManualSwitchTest.testManualClusterSwitch randomly fails
> -----------------------------------------------------------
>
> Key: ISPN-9064
> URL: https://issues.jboss.org/browse/ISPN-9064
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Labels: testsuite_stability
> Fix For: 9.4.0.Final
>
>
> {code}
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.infinispan.client.hotrod.xsite.AbstractHotRodSiteFailoverTest.assertSiteHit(AbstractHotRodSiteFailoverTest.java:146)
> at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.assertSingleSiteHit(SiteManualSwitchTest.java:47)
> at org.infinispan.client.hotrod.xsite.SiteManualSwitchTest.testManualClusterSwitch(SiteManualSwitchTest.java:37)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[JBoss JIRA] (ISPN-9054) Upgrade to Aesh 1.0
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-9054?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9054:
----------------------------------
Fix Version/s: 9.4.0.Final
(was: 9.4.0.CR3)
> Upgrade to Aesh 1.0
> -------------------
>
> Key: ISPN-9054
> URL: https://issues.jboss.org/browse/ISPN-9054
> Project: Infinispan
> Issue Type: Component Upgrade
> Components: CLI
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Fix For: 9.4.0.Final
>
>
> Aesh 1.0 has been released, and is currently used by Wildfly 12.x. 1.0 has several differences to Aesh 0.66.x, most notably the introduction of the aesh-readline project and the removal of AeshConsoleCallback. The upgrade is non-trivial, however due to some of the new features provided by Aesh 1.x, it could greatly reduce the amount of code required.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 6 months
[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: 9.4.0.Final
(was: 9.4.0.CR3)
> Add CodedInputStream.setsize functionality
> ------------------------------------------
>
> Key: ISPN-9031
> URL: https://issues.jboss.org/browse/ISPN-9031
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Lena Herrmann
> Fix For: 9.4.0.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.5.0#75005)
7 years, 6 months