[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-3128:
-------------------------------------------
Ok, thanks guys for clarification. Let's close this one.
> Better support for (Spring) read caching
> ----------------------------------------
>
> Key: ISPN-3128
> URL: https://issues.jboss.org/browse/ISPN-3128
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Affects Versions: 5.3.0.Beta2
> Environment: Spring 3.1+
> Reporter: Mike Noordermeer
> Assignee: Sebastian Łaskawiec
>
> We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
> As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
> - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
> - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
> - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
> - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
> The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
> In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
> - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
> - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
> Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-3128.
-------------------------------------
Resolution: Deferred
> Better support for (Spring) read caching
> ----------------------------------------
>
> Key: ISPN-3128
> URL: https://issues.jboss.org/browse/ISPN-3128
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Affects Versions: 5.3.0.Beta2
> Environment: Spring 3.1+
> Reporter: Mike Noordermeer
> Assignee: Sebastian Łaskawiec
>
> We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
> As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
> - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
> - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
> - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
> - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
> The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
> In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
> - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
> - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
> Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8220) ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8220?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-8220:
------------------------------------
I ran this test locally, in isolation with trace logging, for over 5000 runs and was unable to reproduce this failure :(
> ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
> -----------------------------------------------------------
>
> Key: ISPN-8220
> URL: https://issues.jboss.org/browse/ISPN-8220
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management, Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> {code:java}
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1327)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1793)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:282)
> at org.infinispan.cache.impl.AbstractDelegatingCache.put(AbstractDelegatingCache.java:358)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:655)
> at org.infinispan.jmx.ClusteredCacheMgmtInterceptorMBeanTest.testCorrectStatsInCluster(ClusteredCacheMgmtInterceptorMBeanTest.java:48)
> 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)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:347)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> ... Removed 16 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3128?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-3128:
------------------------------------
[~sebastian.laskawiec] as a partial solution we could use {{putForExternalRead()}} in {{SpringCache.get(Object, Callable)}} for invalidation caches. [~matlach]'s workaround analyzing the stack trace seems too heavy-weight.
We can also raise a bug in Spring to tell caches what annotation triggered the operation. But one can already use {{SpringAOP}} to call {{putForExternalRead()}} if the method has a custom annotation (say {{@LocalCacheable}}), so it's probably not going to be a priority for them.
> Better support for (Spring) read caching
> ----------------------------------------
>
> Key: ISPN-3128
> URL: https://issues.jboss.org/browse/ISPN-3128
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Affects Versions: 5.3.0.Beta2
> Environment: Spring 3.1+
> Reporter: Mike Noordermeer
> Assignee: Sebastian Łaskawiec
>
> We're having a bit of an issue using Infinispan as backing cache for Spring's Caching annotations. The reasons are clear, but I haven't found a proper solution yet. I thought I would describe the issues in a feature request, so we can try to make the necessary changes to fix the situation.
> As already described in [the forums|https://community.jboss.org/thread/201086], an Infinispan cache in invalidation mode sends an invalidation message to other cache nodes if something is put into the cache. This conflicts with Spring's idea of {{@Cacheable}} annotations, which are ment to provide read caching for methods. Imagine the following scenario:
> - Method A is annotated with {{@Cacheable}}, backed by a cache in invalidation mode
> - Node X calls Method A, the method is executed and the return value is locally cached (and an invalidation message is sent to Node Y)
> - Node Y calls Method A, the method is executed and the return value is locally cached, *also, the cache of Node X is invalidated*
> - Node X calls Method A and has to execute the method again, since its cache is gone, etc... etc...
> The reason we want to be able to invalidate the read cache, is because if the application executed an update method for the underlying data (usually marked with {{@CacheEvict}} or {{@CachePut}}) we *do* want to invalidate the other ndoes.
> In Infinispan, this problem can be solved by caching using {{cache.putForExternalRead()}}. That will not invalidate other caches on a put, but will invalidate the cache when asked explicitly. However, simply changing {{put()}} to {{putForExternalRead()}} in {{SpringCache}} leads to a couple of other issues:
> - This is probably not the behaviour everyone wants (people that do not use Spring annotations, but expect the usual Infinispan behaviour).
> - Changing {{put()}} to {{putForExternalRead()}} would break the expected {{@CachePut}} behaviour (a new value is generated, so the old values should be invalidated), but it would fix {{@Cacheable}} behaviour.
> Maybe there should be an option in the factory bean to switch between {{put()}} and {{putForExternalRead()}}? Maybe Spring should change or amend its interface so we can differentiate between calls coming from {{@CachePut}} and calls coming from {{@Cacheable}}? An other option is to make the invalidation behaviour configurable in Infinispan (that's the way Ehcache handles this issue, you can choose if puts or updates should be replicated, or just replicate invalidations).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8218) ScatteredStreamIteratorTest.waitUntilProcessingResults random failure
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-8218?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on ISPN-8218 at 8/24/17 4:33 AM:
------------------------------------------------------------
It looks like the streams don't handle the situation where the local node becomes the only owner after rehash, as the code is already in the remote-part. Such situation does not occur with distributed streams as usually there are 2 owners, but should be reproducible with 1 owner as well.
The core problem seems that local segments set through {{AbstractCacheStream.supplierForSegments}} can differ from the list used by {{CSMI.remoteStreamOperationRehashAware -> determineTargets}} - this is a result of the modifications for scattered cache.
was (Author: rvansa):
It looks like the streams don't handle the situation where the local node becomes the only owner after rehash, as the code is already in the remote-part. Such situation does not occur with distributed streams as usually there are 2 owners, but should be reproducible with 1 owner as well.
> ScatteredStreamIteratorTest.waitUntilProcessingResults random failure
> ---------------------------------------------------------------------
>
> Key: ISPN-8218
> URL: https://issues.jboss.org/browse/ISPN-8218
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
> Attachments: log4.txt
>
>
> To be investigated, log attached. Failure occured in CI: http://ci.infinispan.org/job/Infinispan/job/master/91/
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-7374) Exception caught while executing command org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache '{}_{portname.275213898068544}' is in 'TERMINATED' state
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7374?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7374:
-----------------------------------
This looks like running {{cache.values()}} on a cache that was previously stopped ({{cache.stop()}} - getting an exception is the expected outcome. How are you exactly restarting those nodes, and how does the call relate to the restart?
> Exception caught while executing command org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache '{}_{portname.275213898068544}' is in 'TERMINATED' state
> -------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-7374
> URL: https://issues.jboss.org/browse/ISPN-7374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations
> Affects Versions: 8.2.2.Final
> Reporter: Ankit Tripathi
>
> We are using Opendaylight Controller in a 3 node cluster Env. Which uses infinispan cache for storing and replicating the data in the cluster.
> After rebooting all the 3 nodes, we are observing the below infinispan error.
> Exception caught while executing command
> org.infinispan.IllegalLifecycleStateException: ISPN000323: Cache '{}_{portname.275213898068544}' is in 'TERMINATED' state and so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:101)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> at org.infinispan.commands.AbstractVisitor.visitEntrySetCommand(AbstractVisitor.java:105)
> at org.infinispan.commands.read.EntrySetCommand.acceptVisitor(EntrySetCommand.java:49)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitEntrySetCommand(AbstractVisitor.java:105)
> at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitEntrySetCommand(DistributionBulkInterceptor.java:60)
> at org.infinispan.interceptors.distribution.DistributionBulkInterceptor.visitEntrySetCommand(DistributionBulkInterceptor.java:49)
> at org.infinispan.commands.read.EntrySetCommand.acceptVisitor(EntrySetCommand.java:49)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> at org.infinispan.cache.impl.CacheImpl.cacheEntrySet(CacheImpl.java:624)
> at org.infinispan.cache.impl.CacheImpl.values(CacheImpl.java:612)
> at org.infinispan.cache.impl.CacheImpl.values(CacheImpl.java:608)
> at org.infinispan.cache.impl.CacheImpl.values(CacheImpl.java:126)
> at org.opendaylight.controller.clustering.services_implementation.internal.ExceptionAwareWrapperCache.values(ExceptionAwareWrapperCache.java:236)
> We tried below workaround mentioned in below link. and it worked ( we gave 10 sec delay between node restart in cluster)
> https://bugzilla.redhat.com/show_bug.cgi?id=900946
> we found another link reporting the similar issue(not sure) in higher version.
> https://issues.jboss.org/browse/ISPN-5075
> Please suggest.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months
[JBoss JIRA] (ISPN-8220) ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
by Ryan Emerson (JIRA)
[ https://issues.jboss.org/browse/ISPN-8220?page=com.atlassian.jira.plugin.... ]
Ryan Emerson updated ISPN-8220:
-------------------------------
Labels: testsuite_stability (was: )
> ClusteredCacheMgmtInterceptorMBeanTest fails intermittently
> -----------------------------------------------------------
>
> Key: ISPN-8220
> URL: https://issues.jboss.org/browse/ISPN-8220
> Project: Infinispan
> Issue Type: Bug
> Components: JMX, reporting and management, Test Suite - Core
> Affects Versions: 9.1.0.Final
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Labels: testsuite_stability
> Fix For: 9.1.1.Final
>
>
> {code:java}
> org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.AsyncInterceptorChainImpl.invoke(AsyncInterceptorChainImpl.java:259)
> at org.infinispan.cache.impl.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1679)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1327)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:1793)
> at org.infinispan.cache.impl.CacheImpl.put(CacheImpl.java:282)
> at org.infinispan.cache.impl.AbstractDelegatingCache.put(AbstractDelegatingCache.java:358)
> at org.infinispan.cache.impl.EncoderCache.put(EncoderCache.java:655)
> at org.infinispan.jmx.ClusteredCacheMgmtInterceptorMBeanTest.testCorrectStatsInCluster(ClusteredCacheMgmtInterceptorMBeanTest.java:48)
> 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)
> Caused by: org.infinispan.util.concurrent.TimeoutException: Timed out waiting for topology 6
> at org.infinispan.interceptors.impl.BaseStateTransferInterceptor$CancellableRetry.run(BaseStateTransferInterceptor.java:347)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> ... 3 more
> ... Removed 16 stack frames
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
6 years, 8 months