[JBoss JIRA] (ISPN-3678) In replicated mode writeSkew check is executed only on coordinator
by Radim Vansa (JIRA)
Radim Vansa created ISPN-3678:
---------------------------------
Summary: In replicated mode writeSkew check is executed only on coordinator
Key: ISPN-3678
URL: https://issues.jboss.org/browse/ISPN-3678
Project: Infinispan
Issue Type: Bug
Components: Transactions
Affects Versions: 6.0.0.CR1
Reporter: Radim Vansa
Assignee: Mircea Markus
Priority: Critical
Write skew check should be always performed on primary owner - however, in replicated and invalidation modes this is executed only on the coordinator (and primary owner). The bug is in ClusterDependentLogic.InvalidationLogic.
As a result, two conditional commands (e.g putIfAbsent) may both succeed to set the value.
--
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, 5 months
[JBoss JIRA] (ISPN-3665) SingleFileStore is not thread-safe for passivation
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/ISPN-3665?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated ISPN-3665:
---------------------------------
Fix Version/s: 6.0.0.CR2
> SingleFileStore is not thread-safe for passivation
> --------------------------------------------------
>
> Key: ISPN-3665
> URL: https://issues.jboss.org/browse/ISPN-3665
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.CR1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Priority: Blocker
> Labels: 620
> Fix For: 6.0.0.CR2
>
> Attachments: Test.java
>
>
> SingleFileStore never makes use of FileChannel.force(...) to flush changes to disk. This causes problems for the passivation use case.
> If one thread evicts a cache entry, while immediately after another thread attempts to read the same cache entry, the Cache.get(...) can return null. This is because the entry is never flushed to disk.
> I've attached a test to reproduce the problem.
> I also ran the same test with the addition of FileChannel.force(false) to the write(...) method, and the test succeeds.
> A proper fix should probably make this a configurable property (as it was with the old file store implementation). It would be nice if the flush could defer until just before tx commit, but, off hand, I don't know how feasible that is.
> I suspect this lack of flush also accounts for much of the bold claim of a 100x performance improvement over the old file store implementation.
--
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, 5 months
[JBoss JIRA] (ISPN-3494) org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-3494?page=com.atlassian.jira.plugin.... ]
Martin Gencur reassigned ISPN-3494:
-----------------------------------
Assignee: Sanne Grinovero (was: Anna Manukyan)
> org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3494
> URL: https://issues.jboss.org/browse/ISPN-3494
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.Alpha4
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Labels: testsuite_stability
>
> The test org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion almost always fails during the run on all environments/jdks (Windows, Solaris, RHEL - Oracle JDK 1.7, Open JDK 1.7, IBM JDK 1.7).
> The error is:
> {code}
> java.lang.AssertionError: expected:<false> but was:<true>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:185)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:192)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.checkIfExists(CacheLoaderAPITest.java:331)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion(CacheLoaderAPITest.java:276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {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, 5 months
[JBoss JIRA] (ISPN-3494) org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3494?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3494:
----------------------------------
Assignee: Anna Manukyan (was: Sanne Grinovero)
> org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3494
> URL: https://issues.jboss.org/browse/ISPN-3494
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.Alpha4
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Labels: testsuite_stability
>
> The test org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion almost always fails during the run on all environments/jdks (Windows, Solaris, RHEL - Oracle JDK 1.7, Open JDK 1.7, IBM JDK 1.7).
> The error is:
> {code}
> java.lang.AssertionError: expected:<false> but was:<true>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:185)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:192)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.checkIfExists(CacheLoaderAPITest.java:331)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion(CacheLoaderAPITest.java:276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {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, 5 months
[JBoss JIRA] (ISPN-3494) org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3494?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3494:
---------------------------------------
Hi Anna I'm reassigning this to you until you can confirm the tests, feel free to re-assign to me or Pedro when you know the details.
> org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion test fails periodically
> -------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3494
> URL: https://issues.jboss.org/browse/ISPN-3494
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 6.0.0.Alpha4
> Reporter: Anna Manukyan
> Assignee: Anna Manukyan
> Labels: testsuite_stability
>
> The test org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion almost always fails during the run on all environments/jdks (Windows, Solaris, RHEL - Oracle JDK 1.7, Open JDK 1.7, IBM JDK 1.7).
> The error is:
> {code}
> java.lang.AssertionError: expected:<false> but was:<true>
> at org.testng.AssertJUnit.fail(AssertJUnit.java:59)
> at org.testng.AssertJUnit.failNotEquals(AssertJUnit.java:364)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:80)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:185)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:192)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.checkIfExists(CacheLoaderAPITest.java:331)
> at org.infinispan.lucene.cachestore.CacheLoaderAPITest.testLoadAllKeysWithChunkExclusion(CacheLoaderAPITest.java:276)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:715)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:907)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1237)
> 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)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:724)
> {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, 5 months
[JBoss JIRA] (ISPN-3672) Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3672?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-3672:
---------------------------------------
Looks like a version conflict with Apache Avro.
> Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3672
> URL: https://issues.jboss.org/browse/ISPN-3672
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Sanne Grinovero
> Attachments: MultiHotRodServerIspnDirQueryTest.java, MultiHotRodServerIspnDirReplQueryTest.java, MultiHotRodServerQueryTest.java
>
>
> I've added new tests, where the cache configuration is following:
> 2 clustered HotRod Servers configured with indexing enabled caches and using Infinispan as a directory_provider.
> When the test is putting some data into the caches and then perform query on it, the query doesn't return any results. Even sometimes when getting the entry using key from the first cache, the entry is null.
> The failing tests are MultiHotRodServerIspnDirReplQueryTest and MultiHotRodServerIspnDirQueryTest which are extended from MultiHotRodServerQueryTest.
> In the first case the ISPN directory related caches are replicated, in the second case the caches are local.
> You can find the test attached.
> Also, if I'm trying to add the following line to the cache configuration:
> {code}
> .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager")
> {code}
> then, I'm getting the following exception:
> {code}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.NoSuchMethodError: org.apache.avro.io.BinaryEncoder: method <init>()V not found
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:213)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.client.hotrod.query.MultiHotRodServerQueryTest.testAttributeQuery(MultiHotRodServerQueryTest.java:68)
> {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, 5 months
[JBoss JIRA] (ISPN-3672) Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-3672?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-3672:
----------------------------------
Assignee: Adrian Nistor (was: Sanne Grinovero)
> Remote Query test failure in case of clustered hotrod server configured with Infinispan directory_provider
> ----------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3672
> URL: https://issues.jboss.org/browse/ISPN-3672
> Project: Infinispan
> Issue Type: Bug
> Components: Querying
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Attachments: MultiHotRodServerIspnDirQueryTest.java, MultiHotRodServerIspnDirReplQueryTest.java, MultiHotRodServerQueryTest.java
>
>
> I've added new tests, where the cache configuration is following:
> 2 clustered HotRod Servers configured with indexing enabled caches and using Infinispan as a directory_provider.
> When the test is putting some data into the caches and then perform query on it, the query doesn't return any results. Even sometimes when getting the entry using key from the first cache, the entry is null.
> The failing tests are MultiHotRodServerIspnDirReplQueryTest and MultiHotRodServerIspnDirQueryTest which are extended from MultiHotRodServerQueryTest.
> In the first case the ISPN directory related caches are replicated, in the second case the caches are local.
> You can find the test attached.
> Also, if I'm trying to add the following line to the cache configuration:
> {code}
> .addProperty("default.indexmanager", "org.infinispan.query.indexmanager.InfinispanIndexManager")
> {code}
> then, I'm getting the following exception:
> {code}
> org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2] returned server error (status=0x85): org.infinispan.commons.CacheException: java.lang.NoSuchMethodError: org.apache.avro.io.BinaryEncoder: method <init>()V not found
> at org.infinispan.client.hotrod.impl.protocol.Codec10.checkForErrorsInResponseStatus(Codec10.java:143)
> at org.infinispan.client.hotrod.impl.protocol.Codec10.readHeader(Codec10.java:99)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:46)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:213)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.client.hotrod.query.MultiHotRodServerQueryTest.testAttributeQuery(MultiHotRodServerQueryTest.java:68)
> {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, 5 months
[JBoss JIRA] (ISPN-3677) With optimistic TX, conditional commands may wrongly succeed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3677?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3677:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1026221|https://bugzilla.redhat.com/show_bug.cgi?id=1026221]
> With optimistic TX, conditional commands may wrongly succeed
> ------------------------------------------------------------
>
> Key: ISPN-3677
> URL: https://issues.jboss.org/browse/ISPN-3677
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Situation with optimistic TX, originator = entry's primary owner:
> 1. The conditional check suceeds when the command is executed
> 2. In TxDistributionInterceptor, ignorePreviousValue is set to true
> 3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
> 4. During the prepare/commit phase the command ignores the condition
> Result:
> Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
--
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, 5 months
[JBoss JIRA] (ISPN-3655) Default optimistic locking configuration leads to inconsistency
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3655?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3655:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> made a comment on [bug 1024373|https://bugzilla.redhat.com/show_bug.cgi?id=1024373]
> Default optimistic locking configuration leads to inconsistency
> ---------------------------------------------------------------
>
> Key: ISPN-3655
> URL: https://issues.jboss.org/browse/ISPN-3655
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration, Locking and Concurrency, Transactions
> Affects Versions: 5.3.0.Final, 6.0.0.CR1
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: 620
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> Infinispan transactional caches are configured with optimistic locking by default. Without extra configuration (REPETEABLE_READ + writeSkews), concurrent replace() calls will return true under contention and transactions will commit.
> Under contention, even if replace() returns true for multiple resources, it should rollback all except one transaction.
> When transactional optimistic locking is enabled (default), it should enable all options required to make this scenarios correct.
--
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, 5 months
[JBoss JIRA] (ISPN-3677) With optimistic TX, conditional commands may wrongly succeed
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3677?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3677:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1026221|https://bugzilla.redhat.com/show_bug.cgi?id=1026221] from NEW to CLOSED
> With optimistic TX, conditional commands may wrongly succeed
> ------------------------------------------------------------
>
> Key: ISPN-3677
> URL: https://issues.jboss.org/browse/ISPN-3677
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Mircea Markus
> Priority: Critical
>
> Situation with optimistic TX, originator = entry's primary owner:
> 1. The conditional check suceeds when the command is executed
> 2. In TxDistributionInterceptor, ignorePreviousValue is set to true
> 3. The command is then enlisted in the modifications list with the ignorePreviousValue set to true
> 4. During the prepare/commit phase the command ignores the condition
> Result:
> Two commands, replace(key, A, B), replace(key, A, C) may both overwrite the entry (and the one committed later wins, actually overwriting B instead of A).
--
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, 5 months