[JBoss JIRA] (ISPN-3128) Better support for (Spring) read caching
by Mike Noordermeer (JIRA)
Mike Noordermeer created ISPN-3128:
--------------------------------------
Summary: 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: Mircea Markus
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}}?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3127) Infinispan system requirements
by Kranti Deepak (JIRA)
[ https://issues.jboss.org/browse/ISPN-3127?page=com.atlassian.jira.plugin.... ]
Kranti Deepak commented on ISPN-3127:
-------------------------------------
bash-3.2$ ./startServer.sh
./functions.sh: line 47: syntax error in conditional expression: unexpected token `('
./functions.sh: line 47: syntax error near `/etc($'
./functions.sh: line 47: ` if [[ "$E" =~ /etc($|/) ]]; then'
./startServer.sh: line 5: add_classpath: command not found
./startServer.sh: line 6: add_classpath: command not found
./startServer.sh: line 7: add_classpath: command not found
./startServer.sh: line 8: add_classpath: command not found
./startServer.sh: line 9: add_classpath: command not found
./startServer.sh: line 11: add_jvm_args: command not found
./startServer.sh: line 12: add_jvm_args: command not found
./startServer.sh: line 15: add_jvm_args: command not found
./startServer.sh: line 16: add_jvm_args: command not found
./startServer.sh: line 17: find_tcp_port: command not found
./startServer.sh: line 17: add_jvm_args: command not found
./startServer.sh: line 20: add_jvm_args: command not found
./startServer.sh: line 28: add_program_args: command not found
./startServer.sh: line 30: start: command not found
> Infinispan system requirements
> ------------------------------
>
> Key: ISPN-3127
> URL: https://issues.jboss.org/browse/ISPN-3127
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Kranti Deepak
> Assignee: Mircea Markus
>
> Please specify infinispan system requirements.
> I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3127) Infinispan system requirements
by Kranti Deepak (JIRA)
[ https://issues.jboss.org/browse/ISPN-3127?page=com.atlassian.jira.plugin.... ]
Kranti Deepak updated ISPN-3127:
--------------------------------
Description:
Please specify infinispan system requirements.
I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
> Infinispan system requirements
> ------------------------------
>
> Key: ISPN-3127
> URL: https://issues.jboss.org/browse/ISPN-3127
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Kranti Deepak
> Assignee: Mircea Markus
>
> Please specify infinispan system requirements.
> I have deployed Infinispan on windows xp, windows7 and linux-redhat (all 32 bit) its working good. But unable to start on AIX 64bit version.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3120) StateConsumerImpl can ignore state received during a rebalance
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3120?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3120:
-------------------------------
Fix Version/s: 5.3.0.Final
> StateConsumerImpl can ignore state received during a rebalance
> --------------------------------------------------------------
>
> Key: ISPN-3120
> URL: https://issues.jboss.org/browse/ISPN-3120
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.6.Final, 5.3.0.Beta1
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> This causes random failures in ConcurrentOverlappingLeaveTest and ConcurrentNonOverlappingLeaveTest.
> 1. Starting with a 4-node cluster: [E, F, G, H] (topology 7).
> 2. F leaves, and E sends a REBALANCE_START command with nodes [E, G, H] (topology 8). Some segments are owned by [H] in the current CH and by [H, G] in the pending CH.
> 3. E reports that it finished receiving state with a REBAlANCE_CONFIRM command.
> 4. H leaves, and E sends a CH_UPDATE command with nodes [E, G] (topology 9).
> The segments that were owned by [H] in the previous currentCH are assigned to [E, G] in the new currentCH (otherwise they wouldn't have any owners).
> 5. The StateConsumerImpl on E requests state for the "lost" segments from G.
> 6. G confirms the end of the rebalance as well, and E sends a CH_UPDATE command to end the rebalance (topology 10).
> 7. E sends a REBALANCE_START command to assign all segments for [E, G] (topology 11).
> 8. While the StateConsumerImpl on E is starting the state transfer, it also receives a StateResponseCommand for the lost segments from G.
> 9. Because the structures keeping track of the received state are not properly initialized, E considers it finished receiving state for topology 11.
> 10. E receives a StateResponseCommand from G with actual data, but it ignores it because {{StateConsumerImpl.updatedKeys == null}}.
> {noformat}
> 11:30:39,807 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=7, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=null}
> 11:30:39,810 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=8, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339, NodeH-47370]}}
> 11:30:39,817 DEBUG (transport-thread-3,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 8.
> 11:30:39,832 DEBUG (transport-thread-4,NodeE:dist) [LocalTopologyManagerImpl] Updating local consistent hash(es) for cache dist: new topology = CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,834 DEBUG (transport-thread-4,NodeE:dist) [StateConsumerImpl] Adding inbound state transfer for segments [38, 36, 47, 44, 45] of cache dist
> 11:30:39,853 DEBUG (transport-thread-3,NodeE:dist) [LocalTopologyManagerImpl] Starting local rebalance for cache dist, topology = CacheTopology{id=11, currentCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2, members=[NodeE-51027, NodeG-6339]}}
> 11:30:39,859 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=9}
> 11:30:39,864 DEBUG (remote-thread-1,NodeE:dist) [StateConsumerImpl] Finished receiving of segments for cache dist for topology 11.
> 11:30:39,866 TRACE (transport-thread-5,NodeE:dist) [LocalTopologyManagerImpl] Ignoring consistent hash update 10 for cache dist, we have already received a newer topology 11
> 11:30:39,868 TRACE (remote-thread-1,NodeE:) [InboundInvocationHandlerImpl] Calling perform() on StateResponseCommand{cache=dist, origin=NodeG-6339, topologyId=11}
> 11:30:39,872 TRACE (remote-thread-1,NodeE:dist dist) [EntryWrappingInterceptor] State transfer will not write key/value MagicKey#k3{672f69c9@NodeG-6339}/v3 because it was already updated by somebody else
> 11:30:40,582 ERROR (testng-ConcurrentNonOverlappingLeaveTest:) [UnitTestTestNGListener] Test testTransactional(org.infinispan.distribution.rehash.ConcurrentNonOverlappingLeaveTest) failed.
> java.lang.AssertionError: Fail on owner cache NodeE-51027: dc.get(MagicKey#k3{672f69c9@NodeG-6339}) returned null!
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3114) Cache.putForExternalRead leads to ClassCastException in clustered pessimistic mode
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3114?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3114:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cache.putForExternalRead leads to ClassCastException in clustered pessimistic mode
> ----------------------------------------------------------------------------------
>
> Key: ISPN-3114
> URL: https://issues.jboss.org/browse/ISPN-3114
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Distributed Cache, Transactions
> Affects Versions: 5.2.5.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> The command fails to execute and the exception is logged but it is not propagated to caller:
> {code}
> 2013-05-17 10:58:58,911 TRACE [InvocationContextInterceptor] (main) Exception while executing code, failing silently...
> java.lang.ClassCastException: org.infinispan.context.SingleKeyNonTxInvocationContext cannot be cast to org.infinispan.context.impl.TxInvocationContext
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPutKeyValueCommand(PessimisticLockingInterceptor.java:113)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:54)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:257)
> at org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:193)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:134)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:54)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:216)
> at org.infinispan.statetransfer.StateTransferInterceptor.handleWriteCommand(StateTransferInterceptor.java:194)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPutKeyValueCommand(StateTransferInterceptor.java:136)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:120)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:128)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:92)
> at org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:54)
> at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:82)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:343)
> at org.infinispan.CacheImpl.executeCommandAndCommitIfNeeded(CacheImpl.java:1251)
> at org.infinispan.CacheImpl.putIfAbsentInternal(CacheImpl.java:838)
> at org.infinispan.CacheImpl.putIfAbsent(CacheImpl.java:823)
> at org.infinispan.CacheImpl.putIfAbsent(CacheImpl.java:813)
> at org.infinispan.CacheImpl.putForExternalRead(CacheImpl.java:413)
> at org.infinispan.CacheImpl.putForExternalRead(CacheImpl.java:397)
> at org.infinispan.api.mvcc.PutForExternalReadTest.testBasicPropagation(PutForExternalReadTest.java:204)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3094) Cache.putForExternalRead in DIST transactional mode is not replicated to other members
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3094?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3094:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cache.putForExternalRead in DIST transactional mode is not replicated to other members
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3094
> URL: https://issues.jboss.org/browse/ISPN-3094
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Distributed Cache
> Affects Versions: 5.2.5.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> Since the context is non transactional, no command is enqueued in the transaction's modification list to be replicated at prepare time and also TxDistributionInterceptor does not explicitly replicate the command to other owners immediately after local execution. The command end up executing only on originator. This bug seems to be caused by the DistributionInterceptor class hierarchy refactoring in 5.2.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[JBoss JIRA] (ISPN-3095) Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3095?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3095:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Cache.replace() succeeds on originator but fails randomly on remote owners during state transfer in DIST mode with pessimistic locking
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3095
> URL: https://issues.jboss.org/browse/ISPN-3095
> Project: Infinispan
> Issue Type: Bug
> Components: Core API, Distributed Cache
> Affects Versions: 5.2.5.Final
> Reporter: Adrian Nistor
> Assignee: Adrian Nistor
> Fix For: 5.3.0.CR1, 5.3.0.Final
>
>
> TxDistributionInterceptor.ignorePreviousValueOnBackup() should return true to force backups to apply the update (unless write skew check is enabled). Not doing so might lead to a situation where the key is not available locally yet (state transfer in progress) and will be fetched remotely from another owner that has already executed the conditional command. The previous value check would fail then. The check adds little value on backup owners so it should not be done at all.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months