[JBoss JIRA] (ISPN-8221) RemoteCacheStoreIT.testReadOnly random failures
by Ryan Emerson (JIRA)
Ryan Emerson created ISPN-8221:
----------------------------------
Summary: RemoteCacheStoreIT.testReadOnly random failures
Key: ISPN-8221
URL: https://issues.jboss.org/browse/ISPN-8221
Project: Infinispan
Issue Type: Bug
Affects Versions: 9.1.0.Final
Reporter: Gustavo Fernandes
Assignee: Ryan Emerson
Fix For: 9.1.1.Final
java.lang.AssertionError: expected null, but was:<v1>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:664)
at org.junit.Assert.assertNull(Assert.java:646)
at org.junit.Assert.assertNull(Assert.java:656)
at org.infinispan.server.test.cs.remote.RemoteCacheStoreIT.testReadOnly(RemoteCacheStoreIT.java:85)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (ISPN-8204) Remove should be conditional
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-8204?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-8204:
-----------------------------------
There are many changes in semantic. {{IRV}} flag with non-condition removal will create a {{RemoveCommand}} with {{LoadType}} {{DONT_LOAD}}:
* the context entry isn't mark as read (skips WriteSkew check)
* the value isn't loaded from cache loader if it doesn't exists in {{DataContainer}}
* if the entry doesn't exists in context, it won't be loaded from remote node
* it doesn't create a {{SuccessfulResponse}} (doesn't send the return value)
* in a transaction, it doesn't perform the remote get.
My point is that we lose all the {{IRV}} behavior, and that isn't good IMO. If we go we this changes, we can remove the flag (it is only used in {{put(k,v)}} and create a {{set(k,v)}} method. At least, it can remove a couple of if-branches in the code...
Also, I would like to know what others think about it. If I'm the only one thinking this way, there is no point in waste time to discuss it :)
> Remove should be conditional
> ----------------------------
>
> Key: ISPN-8204
> URL: https://issues.jboss.org/browse/ISPN-8204
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.1.0.Final
> Reporter: Radim Vansa
> Assignee: Radim Vansa
>
> If {{cache.remove(k)}} is called on non-existent key, it should become a no-op, marking the command as unsuccessful, not writing the cache store and not replicating the change to backup owners. That makes the command effectively conditional (as it checks previous value), in the same way as {{cache.replace(k, newValue)}} is.
> While I think that this is the correct behaviour, it's a breaking change for transactions. Some transactions may become read-only and there are multiple tests in the testsuite that would be broken by this.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 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 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)
8 years, 7 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)
8 years, 7 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)
8 years, 7 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)
8 years, 7 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)
8 years, 7 months