[JBoss JIRA] (ISPN-3664) Improve write command processing
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3664?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3664:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Improve write command processing
> --------------------------------
>
> Key: ISPN-3664
> URL: https://issues.jboss.org/browse/ISPN-3664
> Project: Infinispan
> Issue Type: Enhancement
> …
[View More]Components: Core
> Affects Versions: 6.0.0.CR1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1
>
>
> Major refactorization of the write command with the following goals:
> -> Base WriteCommand: all the write command has the same workflow through the interceptor chain
> -> Create a concrete WriteCommand for each operation (put, remove, replace, replaceIfEquals, removeIfEquals, putIfAbsent)
> -> Extend the interceptor chain to process each one of the command and add a new "visitWriteCommand", that is invoked by the default visitX methods.
> -> (minor) change the GetKeyValueCommand to ReadCommand to make name "compatible" with WriteCommand.
> Note that most of the interceptor only needs to implement the visitWriteCommand because all the write command has the same execution flow. The basic flow of the write commands are: (non-tx) lock, fetch value (cachestore/remote), check condition and apply change. for tx mode, lock (if pessimistic), fetch value (cache loader, remote, etc), apply change and add it to the transaction (if successful)
> Also, another advantage is the simplification of the EntryFactory because if we think a little about it, independent of the write command we need to wrap the entry anyway.
> Suggested implementation
> {code:java}
> class abstract WriteCommand
> Object key, Object newValue
> boolen match(Object currentValue) //true by default
> boolean needsRemoteGetBeforeWrite() //true by default
> object perform() //common implementation like: if (match(entry.getValue()) then entry.setValue(newValue); entry.setChanged(true); entry.setRemoved(newValue == null)}
> {code}
> * Concrete implementations*
> {code:java}
> {PutCommand|RemoveCommand} extends WriteCommand
> ovewrite needsRemoteGetBeforeWrite() {return !flags.contains(IGNORE_RETURN_VALUE)}
> ReplaceIfPresentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue != null}
> PutIfAbsentCommand extends WriteCommand
> ovewrite match(Object currentValue) {return currentValue == null}
> {code}
> * Special base class for operation with expected value to compare*
> {code:java}
> class abstract AdvancedWriteCommand extends WriteCommand
> Object expectedValue
> match(Object currentValue) {return currentValue.equals(expectedValue)}
> {RemoveIfEquals|ReplaceIfEquals} extends AdvancedWriteCommand //no different implementation needed.
> {code}
> ps: I'm going to open the discussion in the dev mailing list...
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
[View Less]
10 years, 4 months
[JBoss JIRA] (ISPN-3743) Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3743?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3743:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Silence "IllegalStateException: Default cache is in 'STOPPING' state" exceptions
> --------------------------------------------------------------------------------
>
> Key: ISPN-3743
> URL: https://issues.jboss.org/browse/ISPN-…
[View More]3743
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Labels: testsuite_stability
> Fix For: 7.1.0.Beta1
>
>
> When a cache in STOPPING state receives a command, the exception is propagated all the way to the caller:
> {noformat}
> 09:33:02,005 ERROR (testng-NonTxPutIfAbsentDuringLeaveStressTest:) [UnitTestTestNGListener] Test testNodeLeavingDuringPutIfAbsent(org.infinispan.distribution.rehash.NonTxPutIfAbsentDuringLeaveStressTest) failed.
> java.util.concurrent.ExecutionException: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace
> at java.util.concurrent.FutureTask.report(FutureTask.java:122)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeC-25987, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> Caused by: org.infinispan.remoting.RemoteException: ISPN000217: Received exception from NodeD-57301, see cause for remote stack trace
> at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:41)
> Caused by: java.lang.IllegalStateException: Default cache is in 'STOPPING' state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container.
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:93)
> {noformat}
> This causes random failures in NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent.
> The originator should either ignore the IllegalStateException or wait for a new cache topology and retry the operation, just like it should for SuspectExceptions (ISPN-2577).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
[View Less]
10 years, 4 months
[JBoss JIRA] (ISPN-3727) intermittent test failure AsyncReplExtendedStatisticTest.testReplaceWithOldVal
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3727?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3727:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> intermittent test failure AsyncReplExtendedStatisticTest.testReplaceWithOldVal
> ------------------------------------------------------------------------------
>
> Key: ISPN-3727
> URL: https://issues.jboss.org/browse/ISPN-3727
&…
[View More]gt; Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 6.0.0.Final
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
> Labels: testsuite_stability
> Fix For: 7.1.0.Beta1
>
>
> Failed tests:
> AsyncReplExtendedStatisticTest>BaseClusteredExtendedStatisticTest.testReplaceWithOldVal:190->BaseClusteredExtendedStatisticTest.assertCacheValue:253->MultipleCacheManagersTest.assertEventuallyEquals:554->AbstractInfinispanTest.eventually:173->AbstractInfinispanTest.eventually:45->AbstractInfinispanTest.eventually:62
> expected [true] but found [false]
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
[View Less]
10 years, 4 months
[JBoss JIRA] (ISPN-3716) Shareability of Configuration and ConfigurationBuilder instances (and global versions)
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3716?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3716:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> Shareability of Configuration and ConfigurationBuilder instances (and global versions)
> --------------------------------------------------------------------------------------
>
> Key: ISPN-3716
> URL: https://issues.jboss.org/…
[View More]browse/ISPN-3716
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Reporter: Galder Zamarreño
> Assignee: Mircea Markus
> Fix For: 7.1.0.Beta1
>
>
> Widlfly is using Configuration/GlobalConfiguration instances of one cache/cachemanager to create other cache managers.
> Configuration/GlobalConfiguration are probably not designed to be shareable at this point in time. The builder classes should be sharable but sharing them would not have resolved the issue in ISPN-3698.
> It probably makes sense to change marshaller to be a factory or lookup configuration to be able to create instances of marshaller when configuration is created.
> ConfigurationBuilder/GlobalConfigurationBuilder classes are expected to be shareable.
> Tests and verifications should be added.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
[View Less]
10 years, 4 months
[JBoss JIRA] (ISPN-3795) QueryInterceptor incorrectly relies on the return value of a RemoveCommand
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3795?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3795:
------------------------------
Fix Version/s: 7.1.0.Beta1
(was: 7.1.0.Alpha1)
> QueryInterceptor incorrectly relies on the return value of a RemoveCommand
> --------------------------------------------------------------------------
>
> Key: ISPN-3795
> URL: https://issues.jboss.org/browse/ISPN-3795
> …
[View More] Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Fix For: 7.1.0.Beta1
>
>
> QueryInterceptor uses the return value from RemoveCommand/ReplaceCommand to remove the value from the index.
> But both RemoveCommand and ReplaceCommand have a variant with an expected value parameter, and this variant return a boolean value instead of the removed/replaced value. In that case, the previous value won't be removed from the index.
> QueryInterceptor should probably use the previous value from the context entries to update the index instead.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
[View Less]
10 years, 4 months