March 2019 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9980) Upgrade Spring Version

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9980?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9980: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Beta3 9.4.11.Final Resolution: Done > Upgrade Spring Version > ---------------------- > > Key: ISPN-9980 > URL: https://issues.jboss.org/browse/ISPN-9980 > Project: Infinispan > Issue Type: Component Upgrade > Components: Spring Integration > Reporter: Katia Aresti > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > > Spring 5.1.5.RELEASE > Boot version 2.1.3.RELEASE > Security 5.1.4.RELEASE > Session 2.1.4.RELEASE -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-9463) Provide API to enlist the resource with TransactionManager

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9463?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9463: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Provide API to enlist the resource with TransactionManager > ---------------------------------------------------------- > > Key: ISPN-9463 > URL: https://issues.jboss.org/browse/ISPN-9463 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod, Remote Protocols, Transactions > Reporter: Ramesh Reddy > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta3 > > > Currently, Infinispan will automatically enlist the transaction when a transaction is bound to the executing thread. However, in cases like Teiid where remote access to Infinispan access is wrapped with a resource-adapter (RAR) the resource adapter does the explicit enlisting or delisting. For this there needs to be API provided by Infinispan Cache like > {code} > RemoteCacheManager.getXaResource() > {code} > where it can access the XA resource. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10035) Upgrade to javassist 3.24.1-GA

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10035?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10035: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to javassist 3.24.1-GA > ------------------------------ > > Key: ISPN-10035 > URL: https://issues.jboss.org/browse/ISPN-10035 > Project: Infinispan > Issue Type: Component Upgrade > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Beta3 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10056) Client statistics configuration javadocs

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10056?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10056: ----------------------------------- Fix Version/s: 9.4.11.Final (was: 9.4.10.Final) > Client statistics configuration javadocs > ---------------------------------------- > > Key: ISPN-10056 > URL: https://issues.jboss.org/browse/ISPN-10056 > Project: Infinispan > Issue Type: Enhancement > Components: Documentation-Servers, Hot Rod > Affects Versions: 10.0.0.Beta2, 9.4.9.Final > Reporter: Tristan Tarrant > Priority: Major > Fix For: 9.4.11.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[JBoss JIRA] (ISPN-10055) Checkstyle 8.18

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-10055?page=com.atlassian.jira.plugin... ] Tristan Tarrant updated ISPN-10055: ----------------------------------- Fix Version/s: 9.4.11.Final (was: 9.4.10.Final) > Checkstyle 8.18 > --------------- > > Key: ISPN-10055 > URL: https://issues.jboss.org/browse/ISPN-10055 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build > Affects Versions: 10.0.0.Beta2, 9.4.9.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta3, 9.4.11.Final > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

[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)

7 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2019