[JBoss JIRA] (ISPN-2708) Configuration of infinispan/global/serialization does not work as documented
by Robert Stupp (JIRA)
Robert Stupp created ISPN-2708:
----------------------------------
Summary: Configuration of infinispan/global/serialization does not work as documented
Key: ISPN-2708
URL: https://issues.jboss.org/browse/ISPN-2708
Project: Infinispan
Issue Type: Feature Request
Components: Marshalling
Affects Versions: 5.2.0.CR1
Reporter: Robert Stupp
Assignee: Galder Zamarreño
The definition of element {{marshallerClass}} in {{infinispan-config-5.2.xsd}} says: ??Fully qualified name of the marshaller to use. It must implement org.infinispan.marshall.StreamingMarshaller??.
But if I add a custom marshaller class Infinispan will not start because of a *ClassCastException cannot be cast to org.infinispan.marshall.VersionAwareMarshaller*:
{noformat}
Caused by: org.infinispan.config.ConfigurationException: org.infinispan.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:379) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at com.hrs.frw.commons.cache.infinispan.InfinispanCacheFactoryImpl.afterPropertiesSet(InfinispanCacheFactoryImpl.java:159) [frw-thirdparty-infinispan-dev-SNAPSHOT.jar:20920]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1514) [spring-beans-3.1.1.RELEASE.jar:3.1.1.RELEASE]
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1452) [spring-beans-3.1.1.RELEASE.jar:3.1.1.RELEASE]
... 23 more
Caused by: org.infinispan.CacheException: Unable to construct a GlobalComponentRegistry!
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:146) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:375) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
... 26 more
Caused by: java.lang.ClassCastException: com.....MarshallerImpl cannot be cast to org.infinispan.marshall.VersionAwareMarshaller
at org.infinispan.factories.MarshallerFactory.construct(MarshallerFactory.java:48) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:290) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:246) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:86) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:811) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:220) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:175) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:295) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:272) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:140) [infinispan-core-5.2.0.CR1.jar:5.2.0.CR1]
... 27 more
{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
13 years, 2 months
[JBoss JIRA] (ISPN-2578) Two PrepareCommands in parallel cause ConcurrentModificationException
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2578?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2578:
--------------------------------
Assignee: Mircea Markus (was: Adrian Nistor)
> Two PrepareCommands in parallel cause ConcurrentModificationException
> ---------------------------------------------------------------------
>
> Key: ISPN-2578
> URL: https://issues.jboss.org/browse/ISPN-2578
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.0.Beta5
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Blocker
> Fix For: 5.2.0.CR2
>
>
> Situation:
> 1) Node A broadcasts PrepareCommand to nodes B, C
> 2) Node A leaves cluster, causing new topology to be installed
> 3) The command arrives to B and C, with lower topology than the current one
> 4) Both B and C forward the command to node D
> 5) D executes the two commands in parallel and finds out that A has left, therefore executing RollbackCommand
> In {{AbstractTxLockingInterceptor.visitRollbackCommand}} we call {{LockManagerImpl.unlockAll}} which iterates over the keys and unlocks them. As these two prepares aren't synchronized over the {{lockedKeys}} set, one may unlock and remove these keys while the other is iterating through them, causing {{ConcurrentModificationException}}.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2588 started by Adrian Nistor.
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2588) Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2588?page=com.atlassian.jira.plugin.... ]
Work on ISPN-2588 stopped by Adrian Nistor.
> Lock leak during state transfer (causing StaleLocksTransactionTest to fail)
> ---------------------------------------------------------------------------
>
> Key: ISPN-2588
> URL: https://issues.jboss.org/browse/ISPN-2588
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 5.2.0.Beta5
> Reporter: Mircea Markus
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
> Attachments: StaleLocksTransactionTest.zip
>
>
> numOwners=1, pessimistic cache (same applies if A is the only node in cluster)
> 1. tx1 running on A with writes on k, lockOwner(k) == {A}
> 2. A.tx1.lock(k), this doesn't go remotely, and control returns in the InterceptorStack
> 3. at this point B is started and lockOwner(k) == {B}
> 4. the StateTransferInterceptor forwards the command to B which acquires the lock locally
> 5. this is followed by a tx.commit/rollback that would not send the message to B, so the lock on B is pending.
> The logic which determines whether the message to be sent remotely or not is in DistributionInterceptor.visitCommitCommand, which invokes:
> {code:java}
> protected boolean shouldInvokeRemoteTxCommand(TxInvocationContext ctx) {
> return ctx.isOriginLocal() && (ctx.hasModifications() ||
> !((LocalTxInvocationContext) ctx).getRemoteLocksAcquired().isEmpty());
> }
> {code}
> The problem here is that, when forwarding, we don't register the remote node as a locked.I think a more generic solution would also work, e.g. if the viewId of the tx is different from the viewId of the cluster at commit time, always go remotely.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2326) c3p0 not part of the release
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-2326?page=com.atlassian.jira.plugin.... ]
Adrian Nistor commented on ISPN-2326:
-------------------------------------
As already noted above and in the warning from the user guide there is a known problem with unpredictable dependency resolution for moduleSets since ver 2.2 of the plugin and they will probably be deprecated in future in favor of dependencySets. John Casey pointed out a preferred solution to avoid moduleSets in favor of dependecySets: introduce a separate maven module (on the same level as the other children) with the only purpose of building the distro. This module would have the other children as dependencies and will contain an assembly definition that uses dependencySets to include the wanted binaries into the distro. Unfortunately this does not satisfy our need to include config files, scripts and data files in the distro, so we cannot apply it. We are stuck with fiddling moduleSets.
> c3p0 not part of the release
> ----------------------------
>
> Key: ISPN-2326
> URL: https://issues.jboss.org/browse/ISPN-2326
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 5.2.0.Alpha4
> Reporter: Thomas Fromm
> Assignee: Adrian Nistor
> Priority: Blocker
> Fix For: 5.2.0.CR2
>
>
> According infinispan-5.2.0.Alpha4-all/modules/cachestores/jdbc/runtime-classpath.txt c3p0 lib should be part of the release.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2300) Versioned Transactional Cache issues
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2300?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-2300:
-------------------------------------
{quote}My gut feeling is that to fix this properly there really should be 2 flags, one to indicate if the conditional operation succeeded or not, the 2nd to indicate whether the command should make a change in the container. The latter flag, based on the 1st flag, would decide which value to put in the container, the previous value (if conditional operation failed), or the new value (if conditional flag suceeded).{quote}
We already have two flags (isChanged and WriteCommand.isSuccessful), can't we use these?
> Versioned Transactional Cache issues
> ------------------------------------
>
> Key: ISPN-2300
> URL: https://issues.jboss.org/browse/ISPN-2300
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.0.Alpha3
> Reporter: Pedro Ruivo
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: Commands, Conditional, Transactions, Version
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
>
> Description from http://lists.jboss.org/pipermail/infinispan-dev/2012-September/011205.html
> 1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods
> the test cases)
> In this tests, it was updating the cache entry with a null version. This
> originates later a IllegalStateException when it tries to perform the
> write skew check and the version is null.
> I have fixed this problem in this way: if the command fails (PutCommand,
> RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the
> MvccEntry to avoid to update the entry in the DataContainer.
> 2) testClear in distributed mode
> I have no clear idea how to solve this problem but it looks like the
> PrepareCommand (with the ClearCommand) is not sent to all the nodes in
> the cluster. Then, when I do a get, a remote get is performed and the
> key is still there. I think that it is not the desired behavior.
> 3) testRemoveUnexistingEntry
> In this test, it tries to remove a key that does not exists but it does
> not success due to a NullPointerException. I have looked deeper and I
> check that the transaction's lookup entries map has an entry with [key
> => null] and when it tries to perform the write skew check in that key,
> a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper)
> [1] https://github.com/pruivo/infinispan/tree/t_replace_fix
> [2] https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav...
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2612) Problem broadcasting CH_UPDATE command
by Erik Salter (JIRA)
[ https://issues.jboss.org/browse/ISPN-2612?page=com.atlassian.jira.plugin.... ]
Erik Salter commented on ISPN-2612:
-----------------------------------
Here's a separate group of timeout exceptions, with trace logs on
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.159/server.log.gz
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.155/server.log.gz
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.157/server.log.gz
A sample timeout is when a new view reports, but one node takes 10 seconds (i.e. the ClusterCacheStatus lock is held for this duration) to confirm. Here are those truncated trace logs
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.159/odrm-cluster.txt
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.155/odrm-cluster.txt
https://dl.dropbox.com/u/50401510/ISPN-2612/10.30.12.157/odrm-cluster.txt
> Problem broadcasting CH_UPDATE command
> --------------------------------------
>
> Key: ISPN-2612
> URL: https://issues.jboss.org/browse/ISPN-2612
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.2.0.Beta5
> Reporter: Michal Linhard
> Assignee: Dan Berindei
> Priority: Blocker
> Fix For: 5.2.0.CR2
>
> Attachments: session-cluster.xml, test.zip
>
>
> Infinispan 5.2.0.Beta5
> JGroups 3.2.4.Final
> Steps to reproduce (I'm using two virtual interfaces test1, test2)
> 1. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test1 -Djava.net.preferIPv4Stack=true
> 2. wait 10 sec
> 3. Start org.jboss.qa.jdg.Test with -Djgroups.udp.bind_addr=test2 -Djava.net.preferIPv4Stack=true
> After 5 seconds there should be this timeout exception:
> {code}
> 19:42:14,146 WARN [org.infinispan.topology.CacheTopologyControlCommand] (OOB-2,mlinhard-work-37329) ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=___defaultcache, type=REBALANCE_CONFIRM, sender=mlinhard-work-47337, joinInfo=null, topologyId=1, currentCH=null, pendingCH=null, throwable=null, viewId=1}
> java.util.concurrent.ExecutionException: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
> at java.util.concurrent.FutureTask.get(FutureTask.java:91)
> at org.infinispan.topology.ClusterTopologyManagerImpl.executeOnClusterSync(ClusterTopologyManagerImpl.java:563)
> at org.infinispan.topology.ClusterTopologyManagerImpl.broadcastConsistentHashUpdate(ClusterTopologyManagerImpl.java:349)
> at org.infinispan.topology.ClusterTopologyManagerImpl.handleRebalanceCompleted(ClusterTopologyManagerImpl.java:213)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:160)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:137)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommandFromLocalCluster(CommandAwareRpcDispatcher.java:252)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:219)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:483)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:390)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:248)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:598)
> at org.jgroups.JChannel.up(JChannel.java:703)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1020)
> at org.jgroups.protocols.RSVP.up(RSVP.java:172)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:896)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:736)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:414)
> at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:606)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:187)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1287)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1850)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1823)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.infinispan.CacheException: org.jgroups.TimeoutException: TimeoutException
> at org.infinispan.util.Util.rewrapAsCacheException(Util.java:532)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:152)
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:518)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:545)
> at org.infinispan.topology.ClusterTopologyManagerImpl$2.call(ClusterTopologyManagerImpl.java:542)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> ... 3 more
> Caused by: org.jgroups.TimeoutException: TimeoutException
> at org.jgroups.util.Promise._getResultWithTimeout(Promise.java:145)
> at org.jgroups.util.Promise.getResultWithTimeout(Promise.java:40)
> at org.jgroups.util.AckCollector.waitForAllAcks(AckCollector.java:93)
> at org.jgroups.protocols.RSVP$Entry.block(RSVP.java:287)
> at org.jgroups.protocols.RSVP.down(RSVP.java:118)
> at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1025)
> at org.jgroups.JChannel.down(JChannel.java:718)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.down(MessageDispatcher.java:616)
> at org.jgroups.blocks.RequestCorrelator.sendRequest(RequestCorrelator.java:173)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:360)
> at org.jgroups.blocks.GroupRequest.sendRequest(GroupRequest.java:103)
> at org.jgroups.blocks.Request.execute(Request.java:83)
> at org.jgroups.blocks.MessageDispatcher.cast(MessageDispatcher.java:335)
> at org.jgroups.blocks.MessageDispatcher.castMessage(MessageDispatcher.java:249)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:330)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:145)
> ... 8 more
> {code}
> Analysis:
> These are the messages sent after view change:
> {code}
> test1 test2
> <--- JOIN ----
> ---- REBALANCE_START --->
> <--- StateRequestCommand ----
> ---- StateResponseCommand --->
> <--- REBALANCE_CONFIRM ----
> ---- CH_UPDATE --->
> {code}
> The last CH_UPDATE message is broadcast, test2 successfully processes it, but test1 stays in waiting state, because it for some reason awaits response also from itself - local variable entry in the method RSVP.down
> (https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/...)
> contained local address.
--
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
13 years, 2 months
[JBoss JIRA] (ISPN-2300) Versioned Transactional Cache issues
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-2300?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-2300:
----------------------------------------
@Mircea, that was precisely Pedro's fix but as I said, that causes other issues which are not as easy to fix because of the overloaded use of isChanged. This flag really means: "should the new value be applied to the container?", which based on the code must return true when:
1. A conditional operation succeeds.
2. When an entry in the cache store, should be stored in the cache as a result of an activation, or as result of loading it from the cache to check the result of the conditional operation, and the conditional operation fails to succeeded.
If 1 is true, the new value is updated in the cache. If 1. is false, the old value is loaded into the cache.
The problem that Pedro found is that the conditional operation did not succeed (point 1.), so according to him isChanged=false, but if you do that, the entry is not stored in the cache (point 2.) and other tests fail.
My gut feeling is that to fix this properly there really should be 2 flags, one to indicate if the conditional operation succeeded or not, the 2nd to indicate whether the command should make a change in the container. The latter flag, based on the 1st flag, would decide which value to put in the container, the previous value (if conditional operation failed), or the new value (if conditional flag suceeded).
The fix I submitted is really a stop gap, since separating isChanged into two flags would require further refactoring.
> Versioned Transactional Cache issues
> ------------------------------------
>
> Key: ISPN-2300
> URL: https://issues.jboss.org/browse/ISPN-2300
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.2.0.Alpha3
> Reporter: Pedro Ruivo
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: Commands, Conditional, Transactions, Version
> Fix For: 5.2.0.CR2, 5.2.0.Final
>
>
> Description from http://lists.jboss.org/pipermail/infinispan-dev/2012-September/011205.html
> 1) testPutIfAbsent, testRemoveIfPresent, testReplaceWithOldVal (methods
> the test cases)
> In this tests, it was updating the cache entry with a null version. This
> originates later a IllegalStateException when it tries to perform the
> write skew check and the version is null.
> I have fixed this problem in this way: if the command fails (PutCommand,
> RemoveCommand, ReplaceCommand), I unset the flag CHANGED in the
> MvccEntry to avoid to update the entry in the DataContainer.
> 2) testClear in distributed mode
> I have no clear idea how to solve this problem but it looks like the
> PrepareCommand (with the ClearCommand) is not sent to all the nodes in
> the cluster. Then, when I do a get, a remote get is performed and the
> key is still there. I think that it is not the desired behavior.
> 3) testRemoveUnexistingEntry
> In this test, it tries to remove a key that does not exists but it does
> not success due to a NullPointerException. I have looked deeper and I
> check that the transaction's lookup entries map has an entry with [key
> => null] and when it tries to perform the write skew check in that key,
> a NullPointerException is thrown in here [2] (line 80, WriteSkewHelper)
> [1] https://github.com/pruivo/infinispan/tree/t_replace_fix
> [2] https://github.com/pruivo/infinispan/blob/t_replace_fix/core/src/main/jav...
--
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
13 years, 2 months