[JBoss JIRA] (ISPN-10059) Clustered cache cannot start with exception eviction and segmentation disabled
by Dan Berindei (Jira)
Dan Berindei created ISPN-10059:
-----------------------------------
Summary: Clustered cache cannot start with exception eviction and segmentation disabled
Key: ISPN-10059
URL: https://issues.jboss.org/browse/ISPN-10059
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 9.4.10.Final, 10.0.0.Beta2
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 10.0.0.Beta3, 9.4.11.Final
With segmentation disabled and exception eviction is enabled, {{DataContainerFactory}} creates an instance of {{OffHeapDataContainer}}. Because the cache is clustered and {{OffHeapDataContainer}} implements {{InternalDataContainer}}, {{addSegments()}} will be invoked during startup and will throw {{UnsupportedOperationException}}.
{{LocalTopologyManagerImpl}} sees this as a join problem and retries every 100ms until the state transfer timeout expires (4 minutes by default). However, {{ExceptionEvictionTest}} seems to retry forever when running the full test suite, preventing the generation of any test reports.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-10058) RehashClusterPublisherManagerTest OOME on IBM JDK
by Tristan Tarrant (Jira)
Tristan Tarrant created ISPN-10058:
--------------------------------------
Summary: RehashClusterPublisherManagerTest OOME on IBM JDK
Key: ISPN-10058
URL: https://issues.jboss.org/browse/ISPN-10058
Project: Infinispan
Issue Type: Bug
Components: Test Suite - Core
Affects Versions: 9.4.10.Final, 10.0.0.Beta2
Environment: java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 8.0.5.27 - pxa6480sr5fp27-20190104_01(SR5 FP27))
IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20181219_405297 (JIT enabled, AOT enabled)
OpenJ9 - 3f2d574
OMR - 109ba5b
IBM - e2996d1)
JCL - 20190104_01 based on Oracle jdk8u191-b26
Reporter: Tristan Tarrant
Assignee: William Burns
Attachments: Screenshot from 2019-03-19 08-28-22.png
RehashClusterPublisherManagerTest causes an OOME when run with IBM JDK
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-10051) Cluster stats error after node leaves
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10051?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10051:
-----------------------------------
Fix Version/s: 9.4.11.Final
(was: 9.4.10.Final)
> Cluster stats error after node leaves
> -------------------------------------
>
> Key: ISPN-10051
> URL: https://issues.jboss.org/browse/ISPN-10051
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.9.Final
> Reporter: Dan Berindei
> Assignee: William Burns
> Priority: Major
> Fix For: 9.4.11.Final
>
>
> Up to 9.4.x, {{ClusterCacheStatsImpl}} uses the distributed executor service to collect statistics from all the members of the cache. However, DES will fail with a {{SuspectException}} if one of the cache members is no longer in the cluster view, which is very common (a crashed node is always removed from the cluster view first and from the cache topology later):
> {noformat}
> 23:40:57,029 ERROR [org.infinispan.stats.impl.ClusterCacheStatsImpl] (pool-1-thread-1) Could not execute cluster wide cache stats operation : java.util.concurrent.ExecutionException:
> org.infinispan.remoting.transport.jgroups.SuspectException: ISPN000400: Node rhdg73-server-11-9pl9h was suspected
> {noformat}
> In 10.0.x the distributed executor was removed and stats use the cluster executor, which only works with the cluster view.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-10040) Embedded and server thread pool defaults should be the same
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-10040?page=com.atlassian.jira.plugin... ]
Tristan Tarrant updated ISPN-10040:
-----------------------------------
Fix Version/s: 9.4.11.Final
(was: 9.4.10.Final)
> Embedded and server thread pool defaults should be the same
> -----------------------------------------------------------
>
> Key: ISPN-10040
> URL: https://issues.jboss.org/browse/ISPN-10040
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.2.11.Final, 10.0.0.Beta2, 9.4.9.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta3, 9.4.11.Final
>
>
> Embedded:
> {code:java}
> DEFAULT_THREAD_COUNT.put(REMOTE_COMMAND_EXECUTOR, 200);
> DEFAULT_QUEUE_SIZE.put(REMOTE_COMMAND_EXECUTOR, 0);
> {code}
> Server:
> {code:java}
> REMOTE_COMMAND("remote-command", 25, 25, 100000, 60000),
> {code}
> Using a huge queue is not ok for the remote thread pool, but I missed it before because I assumed the server was using the {{KnownComponentNames}} defaults. We should unify the thread pool defaults in another class with a more topical name and remove {{KnownComponentNames}}.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (ISPN-9852) Invocations waiting for a new topology should resume in parallel
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-9852?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-9852:
----------------------------------
Fix Version/s: 9.4.11.Final
(was: 9.4.10.Final)
> Invocations waiting for a new topology should resume in parallel
> ----------------------------------------------------------------
>
> Key: ISPN-9852
> URL: https://issues.jboss.org/browse/ISPN-9852
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 8.2.11.Final, 10.0.0.Alpha2, 9.4.5.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.Beta3, 9.4.11.Final
>
>
> When a command requires a topology newer than the current topology, it uses {{StateTransferLock.transactionDataFuture()}} to wait for the newer topology. When the tx data is received for the newer topology, some (most?) of the waiting operations do not use a separate executor, instead they are all resumed on the thread that received the tx data. If some operations block (e.g. because of a store), it could take a very long time to finish all the blocked operations.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (IPROTO-90) NPE when writing message having a null field of a boxed primitive type that is also marked required
by Adrian Nistor (Jira)
[ https://issues.jboss.org/browse/IPROTO-90?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated IPROTO-90:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
Integrated in 4.2.x and master
> NPE when writing message having a null field of a boxed primitive type that is also marked required
> ---------------------------------------------------------------------------------------------------
>
> Key: IPROTO-90
> URL: https://issues.jboss.org/browse/IPROTO-90
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 4.3.0.Alpha1, 4.2.3.Final
>
>
> This happens with annotation based marshallers.
> {code}
> java.lang.NullPointerException
> at org.infinispan.protostream.annotations.impl.testdomain.Simple$___ProtostreamGeneratedMarshaller28.writeTo(Simple$___ProtostreamGeneratedMarshaller28.java)
> at org.infinispan.protostream.impl.RawProtobufMarshallerDelegate.marshall(RawProtobufMarshallerDelegate.java:32)
> at org.infinispan.protostream.WrappedMessage.writeMessage(WrappedMessage.java:247)
> at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:186)
> at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:181)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaBuilderTest.testGeneration(ProtoSchemaBuilderTest.java:202)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months
[JBoss JIRA] (IPROTO-90) NPE when writing message having a null field of a boxed primitive type that is also marked required
by Adrian Nistor (Jira)
[ https://issues.jboss.org/browse/IPROTO-90?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated IPROTO-90:
--------------------------------
Fix Version/s: 4.2.3.Final
> NPE when writing message having a null field of a boxed primitive type that is also marked required
> ---------------------------------------------------------------------------------------------------
>
> Key: IPROTO-90
> URL: https://issues.jboss.org/browse/IPROTO-90
> Project: Infinispan ProtoStream
> Issue Type: Bug
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Priority: Major
> Fix For: 4.3.0.Alpha1, 4.2.3.Final
>
>
> This happens with annotation based marshallers.
> {code}
> java.lang.NullPointerException
> at org.infinispan.protostream.annotations.impl.testdomain.Simple$___ProtostreamGeneratedMarshaller28.writeTo(Simple$___ProtostreamGeneratedMarshaller28.java)
> at org.infinispan.protostream.impl.RawProtobufMarshallerDelegate.marshall(RawProtobufMarshallerDelegate.java:32)
> at org.infinispan.protostream.WrappedMessage.writeMessage(WrappedMessage.java:247)
> at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:186)
> at org.infinispan.protostream.ProtobufUtil.toWrappedByteArray(ProtobufUtil.java:181)
> at org.infinispan.protostream.annotations.impl.ProtoSchemaBuilderTest.testGeneration(ProtoSchemaBuilderTest.java:202)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 9 months