[JBoss JIRA] (ISPN-10887) GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-10887?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated ISPN-10887:
---------------------------------
Fix Version/s: 10.1.0.Beta1
(was: 10.1.0.CR1)
> GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10887
> URL: https://issues.redhat.com/browse/ISPN-10887
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.1.0.Beta1
>
>
> The feature is supposed to allow detection of an already occupied jmx domain and generate a new unique one by adding an increasing number suffix. The implementation polls the MBeanServer registry using queryNames until a free domain is found. The unique domain generation and the registration of the first MBean to occupy it is not atomic, so multiple CacheManagers starting up concurrently can mistakenly pick up the same domain.
> This can be fixed by making it atomic, by not using queryNames and instead directly registering the first bean, retrying if InstanceAlreadyExistsException. The first bean has to be picked identically by all cache managers. We'll pick first the cache manager itself and register the other components afterwards.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10887) GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-10887?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated ISPN-10887:
---------------------------------
Fix Version/s: (was: 10.0.2.Final)
> GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10887
> URL: https://issues.redhat.com/browse/ISPN-10887
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.1.0.CR1
>
>
> The feature is supposed to allow detection of an already occupied jmx domain and generate a new unique one by adding an increasing number suffix. The implementation polls the MBeanServer registry using queryNames until a free domain is found. The unique domain generation and the registration of the first MBean to occupy it is not atomic, so multiple CacheManagers starting up concurrently can mistakenly pick up the same domain.
> This can be fixed by making it atomic, by not using queryNames and instead directly registering the first bean, retrying if InstanceAlreadyExistsException. The first bean has to be picked identically by all cache managers. We'll pick first the cache manager itself and register the other components afterwards.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10887) GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
by Nistor Adrian (Jira)
[ https://issues.redhat.com/browse/ISPN-10887?page=com.atlassian.jira.plugi... ]
Nistor Adrian updated ISPN-10887:
---------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently
> ------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10887
> URL: https://issues.redhat.com/browse/ISPN-10887
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management
> Affects Versions: 10.0.0.Final
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 10.1.0.CR1, 10.0.2.Final
>
>
> The feature is supposed to allow detection of an already occupied jmx domain and generate a new unique one by adding an increasing number suffix. The implementation polls the MBeanServer registry using queryNames until a free domain is found. The unique domain generation and the registration of the first MBean to occupy it is not atomic, so multiple CacheManagers starting up concurrently can mistakenly pick up the same domain.
> This can be fixed by making it atomic, by not using queryNames and instead directly registering the first bean, retrying if InstanceAlreadyExistsException. The first bean has to be picked identically by all cache managers. We'll pick first the cache manager itself and register the other components afterwards.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-11028) org.infinispan:infinispan-spring5-common missing from infinispan-bom
by Pedro Ruivo (Jira)
[ https://issues.redhat.com/browse/ISPN-11028?page=com.atlassian.jira.plugi... ]
Pedro Ruivo closed ISPN-11028.
------------------------------
> org.infinispan:infinispan-spring5-common missing from infinispan-bom
> --------------------------------------------------------------------
>
> Key: ISPN-11028
> URL: https://issues.redhat.com/browse/ISPN-11028
> Project: Infinispan
> Issue Type: Bug
> Components: Build
> Affects Versions: 9.4.16.Final, 10.1.0.Beta1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 9.4.17.Final, 10.1.0.CR1
>
>
> {{org.infinispan:infinispan-spring5-common}} is missing from {{infinispan-bom}}.
> It causes problems in {{infinispan-spring-boot-starter}} project as maven downloads the wrong version (as shown below):
> {code}
> [INFO] org.infinispan:infinispan-spring-boot-starter-embedded:jar:2.1.8-SNAPSHOT
> [INFO] \- org.infinispan:infinispan-spring5-embedded:jar:9.4.17-SNAPSHOT:compile
> [INFO] \- org.infinispan:infinispan-spring5-common:jar:9.4.16.Final:compile
> {code}
> {{org.infinispan:infinispan-spring5-common}} was added to {{spring-boot-dependencies}} bom and since it is missing from our {{infinispan-bom}}, maven choose whatever version is declared in {{spring-boot-dependencies}}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10984) StackOverflowError following restart of scattered-cache with state-transfer awaitInitialTransfer disabled
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-10984?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-10984:
--------------------------------
Status: Open (was: New)
> StackOverflowError following restart of scattered-cache with state-transfer awaitInitialTransfer disabled
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10984
> URL: https://issues.redhat.com/browse/ISPN-10984
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.16.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Critical
>
> {noformat}
> 2019-11-24 18:30:00,837 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.jboss.msc.service.StartException in service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:651)
> at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.util.IteratorMapper.hasNext(IteratorMapper.java:27)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.schedule(InfinispanSessionManagerFactory.java:232)
> at org.wildfly.clustering.web.infinispan(a)18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.<init>(InfinispanSessionManagerFactory.java:120)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:92)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:69)
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67)
> ... 8 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:649)
> ... 14 more
> Caused by: java.lang.StackOverflowError
> at java.base/java.lang.Throwable.getMessage(Throwable.java:382)
> at java.base/java.lang.Throwable.getLocalizedMessage(Throwable.java:396)
> at java.base/java.lang.Throwable.toString(Throwable.java:485)
> at java.base/java.lang.Throwable.<init>(Throwable.java:316)
> at java.base/java.lang.Exception.<init>(Exception.java:102)
> at java.base/java.lang.RuntimeException.<init>(RuntimeException.java:96)
> at java.base/java.util.concurrent.CompletionException.<init>(CompletionException.java:88)
> at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ...etc...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-10984) StackOverflowError following restart of scattered-cache with state-transfer awaitInitialTransfer disabled
by Dan Berindei (Jira)
[ https://issues.redhat.com/browse/ISPN-10984?page=com.atlassian.jira.plugi... ]
Dan Berindei updated ISPN-10984:
--------------------------------
Sprint: DataGrid Sprint #37
> StackOverflowError following restart of scattered-cache with state-transfer awaitInitialTransfer disabled
> ---------------------------------------------------------------------------------------------------------
>
> Key: ISPN-10984
> URL: https://issues.redhat.com/browse/ISPN-10984
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.4.16.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Critical
>
> {noformat}
> 2019-11-24 18:30:00,837 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.jboss.msc.service.StartException in service jboss.clustering.web."clusterbench-ee8.ear.clusterbench-ee8-web.war": org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:70)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
> at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
> at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:651)
> at org.infinispan.commons@9.4.16.Final//org.infinispan.commons.util.IteratorMapper.hasNext(IteratorMapper.java:27)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.schedule(InfinispanSessionManagerFactory.java:232)
> at org.wildfly.clustering.web.infinispan(a)18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactory.<init>(InfinispanSessionManagerFactory.java:120)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:92)
> at org.wildfly.clustering.web.infinispan@18.0.1.Final//org.wildfly.clustering.web.infinispan.session.InfinispanSessionManagerFactoryServiceConfigurator.get(InfinispanSessionManagerFactoryServiceConfigurator.java:69)
> at org.wildfly.clustering.service@18.0.1.Final//org.wildfly.clustering.service.FunctionalService.start(FunctionalService.java:67)
> ... 8 more
> Caused by: java.util.concurrent.ExecutionException: java.lang.StackOverflowError
> at java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
> at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2022)
> at org.infinispan@9.4.16.Final//org.infinispan.interceptors.impl.PrefetchInterceptor$BackingIterator.hasNext(PrefetchInterceptor.java:649)
> ... 14 more
> Caused by: java.lang.StackOverflowError
> at java.base/java.lang.Throwable.getMessage(Throwable.java:382)
> at java.base/java.lang.Throwable.getLocalizedMessage(Throwable.java:396)
> at java.base/java.lang.Throwable.toString(Throwable.java:485)
> at java.base/java.lang.Throwable.<init>(Throwable.java:316)
> at java.base/java.lang.Exception.<init>(Exception.java:102)
> at java.base/java.lang.RuntimeException.<init>(RuntimeException.java:96)
> at java.base/java.util.concurrent.CompletionException.<init>(CompletionException.java:88)
> at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1113)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.valuesFuture(ScatteredVersionManagerImpl.java:348)
> at org.infinispan@9.4.16.Final//org.infinispan.scattered.impl.ScatteredVersionManagerImpl.lambda$valuesFuture$3(ScatteredVersionManagerImpl.java:348)
> at java.base/java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> at java.base/java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ...etc...
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months
[JBoss JIRA] (ISPN-11020) Clustered Max Idle Take 2
by Will Burns (Jira)
[ https://issues.redhat.com/browse/ISPN-11020?page=com.atlassian.jira.plugi... ]
Will Burns commented on ISPN-11020:
-----------------------------------
Issues to work through:
# Expiration is currently done inside the DataContainer which doesn't have a non blocking based API (need to extract)
# Staggered gets will be problematic
# Stores and off heap need to be update values on retrieval
# Should putIfAbsent or other conditional commands update (putIfAbsent really should)
Nice to haves:
# Enhance to check for not having expired entries and bypassing for things like size?
> Clustered Max Idle Take 2
> -------------------------
>
> Key: ISPN-11020
> URL: https://issues.redhat.com/browse/ISPN-11020
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core, Expiration
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
>
> ISPN-9003 added in clustered max idle expiration. However the approach implemented can cause entries to entries to expire prematurely when a node is lost (due to only the primary having the latest access time). This was deemed not acceptable.
> The new approach will add a new touch command that is fired on an entry access of a max idle entry. This will slow down accesses as they will essentially be light weight synchronous writes, but should guarantee data is properly expired.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 4 months