March 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8923) PersistenceManagerCloseableSupplier can timeout if store produces entries too fast

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8923?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8923: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: (was: 9.3.0.Final) Assignee: William Burns Resolution: Done > PersistenceManagerCloseableSupplier can timeout if store produces entries too fast > ---------------------------------------------------------------------------------- > > Key: ISPN-8923 > URL: https://issues.jboss.org/browse/ISPN-8923 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final, 9.1.7.Final > > > PersistenceManagerCloseableSupplier get method polls the queue then locks the lock. It doesn't recheck the queue inside the lock. Thus if a loader fills up the entire queue before the get method can acquire the lock, this will cause the get method to timeout. Instead we should change the check inside the lock to always poll the queue. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8924) SingleFileStore can run process method substantially faster when it doesn't require values or metadata

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8924?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8924: ---------------------------------- Fix Version/s: (was: 9.3.0.Alpha1) > SingleFileStore can run process method substantially faster when it doesn't require values or metadata > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-8924 > URL: https://issues.jboss.org/browse/ISPN-8924 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final > > > The SingleFileStore always reads from the file. However if value and metadata are both not needed, there is no reason to go to the file. Instead we can just check the expiration on the file entry and return the keys immediately. > This along with ISPN-8923 will provide a SUBSTANTIAL boost for keySet iteration methods when using SingleFileStore. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8924) SingleFileStore can run process method substantially faster when it doesn't require values or metadata

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8924?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8924: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > SingleFileStore can run process method substantially faster when it doesn't require values or metadata > ------------------------------------------------------------------------------------------------------ > > Key: ISPN-8924 > URL: https://issues.jboss.org/browse/ISPN-8924 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.1.Final > > > The SingleFileStore always reads from the file. However if value and metadata are both not needed, there is no reason to go to the file. Instead we can just check the expiration on the file entry and return the keys immediately. > This along with ISPN-8923 will provide a SUBSTANTIAL boost for keySet iteration methods when using SingleFileStore. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8932) Add dependency-check-maven plugin

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8932?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8932: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final Resolution: Done > Add dependency-check-maven plugin > --------------------------------- > > Key: ISPN-8932 > URL: https://issues.jboss.org/browse/ISPN-8932 > Project: Infinispan > Issue Type: Bug > Components: Build > Affects Versions: 9.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.2.1.Final > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8939) Unsafe iteration over non-concurrent data structure in StateReceiverImpl.

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8939?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8939: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final Resolution: Done > Unsafe iteration over non-concurrent data structure in StateReceiverImpl. > ------------------------------------------------------------------------- > > Key: ISPN-8939 > URL: https://issues.jboss.org/browse/ISPN-8939 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 9.2.1.Final > > > {noformat} > 16:39:56,137 WARN [org.infinispan.factories.ComponentRegistry] (ServerService Thread Pool -- 74) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.conflict.impl.StateReceiverImpl.stop() on object of type StateReceiverImpl > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:83) > at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71) > at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968) > at org.infinispan.factories.AbstractComponentRegistry.lambda$internalStop$7(AbstractComponentRegistry.java:741) > at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72) > at org.infinispan.security.Security.doPrivileged(Security.java:76) > at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71) > at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:734) > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:639) > at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:256) > at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1046) > at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1010) > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:420) > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:420) > at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.accept(CacheBuilder.java:78) > at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.accept(CacheBuilder.java:54) > at org.wildfly.clustering.service.SuppliedValueService.lambda$new$1(SuppliedValueService.java:44) > at org.wildfly.clustering.service.FunctionalValueService.stop(FunctionalValueService.java:78) > at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$stop$1(AsynchronousServiceBuilder.java:124) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap.forEach(HashMap.java:1292) > at org.infinispan.conflict.impl.StateReceiverImpl$SegmentRequest.cancel(StateReceiverImpl.java:203) > at org.infinispan.conflict.impl.StateReceiverImpl.stop(StateReceiverImpl.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > ... 26 more > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8938) CacheNotifier should use the cache member and not the view members

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8938?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8938: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final 9.3.0.Alpha1 Resolution: Done > CacheNotifier should use the cache member and not the view members > ------------------------------------------------------------------ > > Key: ISPN-8938 > URL: https://issues.jboss.org/browse/ISPN-8938 > Project: Infinispan > Issue Type: Bug > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.1.Final, 9.3.0.Alpha1 > > > When a clustered listener is registered, the {{CacheNotifierImpl}} is using the view members to register a remote listener but the {{DistributorExecutorService}} is using the cache-members. The missing members (not in the cache) are silently discarded (via {{SuspectException}}). > If a member is joining the cache concurrently, the remote listener may never been installed. as an example (node-a, node-b, and node-c is joining): > {code:java} > view is {a,b,c} in all the nodes > node-a: receives join from node-c > node-a: sends the remote listeners > node-b: registers a new clustered listener. node-c doesn't receive it because it isn't a member in this node > node-a: starts rebalance and continues with normal state transfer > node-c is never aware of the listener of b > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8792) EntryWrappingInterceptorDoesNotBlockTest random failures

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8792?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8792: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final 9.3.0.Alpha1 Resolution: Done > EntryWrappingInterceptorDoesNotBlockTest random failures > -------------------------------------------------------- > > Key: ISPN-8792 > URL: https://issues.jboss.org/browse/ISPN-8792 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.CR2 > Reporter: Radim Vansa > Assignee: Radim Vansa > Fix For: 9.2.1.Final, 9.3.0.Alpha1 > > > PrepareExpectingInterceptor (at the top of the stack) expects that the invocationstage is receives is not complete. When a remote get is completed before the interceptor gets the stage, the stage can get completed, too, and an assertion fires. > Subsequently the latch in the interceptor is not decremented and {{await}} throws a TimeoutException, failing the test. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8854) NullPointerException in SingleFileStore

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8854?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8854: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.2.1.Final 9.3.0.Alpha1 Resolution: Done > NullPointerException in SingleFileStore > --------------------------------------- > > Key: ISPN-8854 > URL: https://issues.jboss.org/browse/ISPN-8854 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.1.Final, 9.3.0.Alpha1 > > > See linked JIRA for description -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8831) Support for Accept-Encoding and Content-Encoding handling in the REST Server

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8831?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8831: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 10.0.0.Final 9.2.1.Final 9.3.0.Alpha1 Resolution: Done > Support for Accept-Encoding and Content-Encoding handling in the REST Server > ---------------------------------------------------------------------------- > > Key: ISPN-8831 > URL: https://issues.jboss.org/browse/ISPN-8831 > Project: Infinispan > Issue Type: Enhancement > Components: REST > Affects Versions: 9.2.0.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 10.0.0.Final, 9.2.1.Final, 9.3.0.Alpha1 > > > As per https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html, enabling content to be transferred as gzip -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (ISPN-8939) Unsafe iteration over non-concurrent data structure in StateReceiverImpl.

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-8939?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated ISPN-8939: ------------------------------- Status: Open (was: New) > Unsafe iteration over non-concurrent data structure in StateReceiverImpl. > ------------------------------------------------------------------------- > > Key: ISPN-8939 > URL: https://issues.jboss.org/browse/ISPN-8939 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 9.2.0.Final > Reporter: Paul Ferraro > > {noformat} > 16:39:56,137 WARN [org.infinispan.factories.ComponentRegistry] (ServerService Thread Pool -- 74) ISPN000189: While stopping a cache or cache manager, one of its components failed to stop: org.infinispan.commons.CacheException: Unable to invoke method public void org.infinispan.conflict.impl.StateReceiverImpl.stop() on object of type StateReceiverImpl > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:83) > at org.infinispan.commons.util.SecurityActions.doPrivileged(SecurityActions.java:71) > at org.infinispan.commons.util.SecurityActions.invokeAccessibly(SecurityActions.java:76) > at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:185) > at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:968) > at org.infinispan.factories.AbstractComponentRegistry.lambda$internalStop$7(AbstractComponentRegistry.java:741) > at org.infinispan.factories.SecurityActions.lambda$run$1(SecurityActions.java:72) > at org.infinispan.security.Security.doPrivileged(Security.java:76) > at org.infinispan.factories.SecurityActions.run(SecurityActions.java:71) > at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:734) > at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:639) > at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:256) > at org.infinispan.cache.impl.CacheImpl.performImmediateShutdown(CacheImpl.java:1046) > at org.infinispan.cache.impl.CacheImpl.stop(CacheImpl.java:1010) > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:420) > at org.infinispan.cache.impl.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:420) > at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.accept(CacheBuilder.java:78) > at org.wildfly.clustering.infinispan.spi.service.CacheBuilder.accept(CacheBuilder.java:54) > at org.wildfly.clustering.service.SuppliedValueService.lambda$new$1(SuppliedValueService.java:44) > at org.wildfly.clustering.service.FunctionalValueService.stop(FunctionalValueService.java:78) > at org.wildfly.clustering.service.AsynchronousServiceBuilder.lambda$stop$1(AsynchronousServiceBuilder.java:124) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:485) > Caused by: java.util.ConcurrentModificationException > at java.util.HashMap.forEach(HashMap.java:1292) > at org.infinispan.conflict.impl.StateReceiverImpl$SegmentRequest.cancel(StateReceiverImpl.java:203) > at org.infinispan.conflict.impl.StateReceiverImpl.stop(StateReceiverImpl.java:66) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.infinispan.commons.util.SecurityActions.lambda$invokeAccessibly$0(SecurityActions.java:79) > ... 26 more > {noformat} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 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 2018