[JBoss JIRA] (ISPN-3764) ISPN testsuite fails for RHEL6x64 && IBM JDK6
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3764?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3764:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1034759|https://bugzilla.redhat.com/show_bug.cgi?id=1034759] from MODIFIED to ON_QA
> ISPN testsuite fails for RHEL6x64 && IBM JDK6
> ----------------------------------------------
>
> Key: ISPN-3764
> URL: https://issues.jboss.org/browse/ISPN-3764
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 6.0.0.Final
> Environment: RHEL6x64 IBM6
> Reporter: Vitalii Chepeliuk
> Assignee: William Burns
> Priority: Critical
> Labels: 620, testsuite_stability
>
> Sometimes build is stucked and sometiemes it throws following exception when CORE module is running
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! (testng-DistWriteSkewTest) Exiting because DistWriteSkewTest has NOT shut down all the cache managers it has started !!!!!!!
> !!!!!! (testng-DistWriteSkewTest) See allocation stacktrace to find out where still-running cacheManager was created: !!!!!!!
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> java.lang.Throwable
> at org.infinispan.test.fwk.TestCacheManagerFactory.addThreadCacheManager(TestCacheManagerFactory.java:373)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:356)
> at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:68)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:160)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151)
> at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:125)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:177)
> at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:162)
> at org.infinispan.test.MultipleCacheManagersTest.createCluster(MultipleCacheManagersTest.java:196)
> at org.infinispan.container.versioning.AbstractClusteredWriteSkewTest.createCacheManagers(AbstractClusteredWriteSkewTest.java:59)
> at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:69)
> at org.infinispan.test.MultipleCacheManagersTest.createBeforeMethod(MultipleCacheManagersTest.java:79)
> at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> Add link to jenkins job
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
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
11 years, 12 months
[JBoss JIRA] (ISPN-3829) Null value read with RR can be replaced by cache loader value
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3829?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3829:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1045579|https://bugzilla.redhat.com/show_bug.cgi?id=1045579] from MODIFIED to ON_QA
> Null value read with RR can be replaced by cache loader value
> -------------------------------------------------------------
>
> Key: ISPN-3829
> URL: https://issues.jboss.org/browse/ISPN-3829
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: William Burns
> Assignee: William Burns
> Labels: 620
> Fix For: 7.0.0.Final
>
>
> Currently the CacheLoaderInterceptor does the following check to determine if it should check the loader for a value
> {code}
> if (e == null || e.isNull() || e.getValue() == null) {
> {code}
> Unfortunately this means it checks the loader when a null value is in the entry when using RR. This can cause an issue if another transaction commits that key and puts a value that results in that value being inserted into the loader.
> This also is a performance issue for RR, since it has to check the loader over and over for a given key even if it was found null the first time.
> Initial thought is to do something like setSkipRemoteGet and that could actually be used for a dual purpose possibly.
--
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
11 years, 12 months
[JBoss JIRA] (ISPN-3738) Entry version gets lost during topology change -> NPE
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3738?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3738:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1032693|https://bugzilla.redhat.com/show_bug.cgi?id=1032693] from MODIFIED to ON_QA
> Entry version gets lost during topology change -> NPE
> -----------------------------------------------------
>
> Key: ISPN-3738
> URL: https://issues.jboss.org/browse/ISPN-3738
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Pedro Ruivo
> Priority: Critical
> Labels: 620
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> Replicated TX cache with WSC, A, B are in cluster, C is joining
> 0. The current CH already contains A and B as owners, C is joining (is not primary owner of anything yet). B is primary owner of K=V.
> 1. A sends PrepareCommand to B and C with put(K, V) (V is null on all nodes)
> 2. C receives PrepareCommand and responds with no versions (it is not primary owner)
> 3. topology changes on B - primary ownership of K is transfered to C
> 4. B receives PrepareCommand, responds without K's version (it is not primary)
> 5. B forwards the Prepare to C as it sees that the command has lower topology ID
> 6. C responds to B's prepare with version of K
> 7. K version is *not* added to B's response, B responds to A
> 8. A finds out that topology has changed, forwards prepare to C
> 9. C responds to C's prepare with version of K
> 10. A receives C's response, but the versions are not added to transaction
> 11. A sends out CommitCommand missing version of K
> 12. all nodes record K=V without version as usual ImmortalCacheEntry
> 13. the next time we try to increase version of K=V, we fail with NPE in SimpleClusteredVersionGenerator (actually when it tries to throw IllegalArgumentException because the null version is unexpected version class)
--
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
11 years, 12 months
[JBoss JIRA] (ISPN-3704) StateTransfer's PutKeyValueCommand may trigger remote get
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3704?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3704:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1032050|https://bugzilla.redhat.com/show_bug.cgi?id=1032050] from MODIFIED to ON_QA
> StateTransfer's PutKeyValueCommand may trigger remote get
> ---------------------------------------------------------
>
> Key: ISPN-3704
> URL: https://issues.jboss.org/browse/ISPN-3704
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.CR1
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> In TX mode with write skew check on, ST executing puts may trigger a remote get.
> The condition in TxDistributionInterceptor.handleTxWriteCommand should probably be switched from
> {code}
> if (ctx.isOriginLocal() && !skipRemoteGet || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> to
> {code}
> if (!skipRemoteGet && (ctx.isOriginLocal() || command.isConditional() || shouldFetchRemoteValuesForWriteSkewCheck(ctx, command)))
> remoteGetBeforeWrite(ctx, command, recipientGenerator);
> {code}
> EDIT:
> I have also registered a situation where the Prepare/Commit command was executed remotely from within the ST because the topology has changed during the remote get. This should be avoided as well.
--
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
11 years, 12 months
[JBoss JIRA] (ISPN-3745) Forwarded Prepare/Commit executed after transaction finished
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3745?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3745:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1033087|https://bugzilla.redhat.com/show_bug.cgi?id=1033087] from MODIFIED to ON_QA
> Forwarded Prepare/Commit executed after transaction finished
> ------------------------------------------------------------
>
> Key: ISPN-3745
> URL: https://issues.jboss.org/browse/ISPN-3745
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 7.0.0.Alpha1
>
>
> Replicated TX cache, nodes A, B, C
> 0. A and B have topology 2, C already got topology 3
> 1. A sends prepare with topology 2 to B and C, both apply the prepare and respond
> 2. C forwards prepare to B with topology 3
> 3. A sends commit with topology 2 to B and C, both commit and respond
> 4. again, C forwards prepare to B with topology 3
> 5. A and B get updated topology id
> 6. A executes another transaction on the same entry
> 7. prepare and commit from first transaction with topology 3 arrive at B - B overwrites (or removes) the entry again
> Result: on B we have inconsistent state
--
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
11 years, 12 months
[JBoss JIRA] (ISPN-3846) CNFE: java.util.RegularEnumSet on IBM JDK 1.6
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3846?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3846:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1044480|https://bugzilla.redhat.com/show_bug.cgi?id=1044480] from MODIFIED to ON_QA
> CNFE: java.util.RegularEnumSet on IBM JDK 1.6
> ---------------------------------------------
>
> Key: ISPN-3846
> URL: https://issues.jboss.org/browse/ISPN-3846
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Environment: IBM Java:
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxa6460sr13ifix-20130303_02(SR13+IV37419))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr13-20130114_134867 (JIT enabled, AOT enabled)
> J9VM - 20130114_134867
> JIT - r9_20130108_31100
> GC - 20121212_AA)
> JCL - 20130303_02
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
> Fix For: 6.0.2.Final
>
>
> I'm getting the following exception when running tests from ISPN core on IBM JDK 1.6.
> I checked that the class is not present in the JVM. However, it is present in IBM JDK 1.7
> {code}
> org.infinispan.commons.CacheConfigurationException: Unable to instantiate class java.util.RegularEnumSet
> at org.infinispan.commons.util.Util.loadClass(Util.java:85)
> at org.infinispan.marshall.exts.EnumSetExternalizer.getEnumSetClass(EnumSetExternalizer.java:87)
> at org.infinispan.marshall.exts.EnumSetExternalizer.getRegularEnumSetClass(EnumSetExternalizer.java:83)
> at org.infinispan.marshall.exts.EnumSetExternalizer.<init>(EnumSetExternalizer.java:35)
> at org.infinispan.marshall.core.ExternalizerTable.loadInternalMarshallables(ExternalizerTable.java:220)
> at org.infinispan.marshall.core.ExternalizerTable.start(ExternalizerTable.java:144)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:207)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:147)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.InternalCacheFactory.bootstrap(InternalCacheFactory.java:79)
> at org.infinispan.factories.InternalCacheFactory.createAndWire(InternalCacheFactory.java:58)
> at org.infinispan.factories.InternalCacheFactory.createCache(InternalCacheFactory.java:42)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:371)
> at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:32)
> at org.infinispan.test.SingleCacheManagerTest.createBeforeMethod(SingleCacheManagerTest.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> 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)
> 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:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:908)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:931)
> at java.lang.Thread.run(Thread.java:738)
> Caused by: java.lang.ClassNotFoundException: java.util.RegularEnumSet
> at java.lang.Class.forName(Class.java:217)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:122)
> at org.infinispan.commons.util.Util.loadClass(Util.java:83)
> ... 102 more
> {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
11 years, 12 months
[JBoss JIRA] (ISPN-3737) L1 requestor registered after value read
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3737?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3737:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1032545|https://bugzilla.redhat.com/show_bug.cgi?id=1032545] from POST to ON_QA
> L1 requestor registered after value read
> ----------------------------------------
>
> Key: ISPN-3737
> URL: https://issues.jboss.org/browse/ISPN-3737
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Priority: Critical
> Labels: 620
> Fix For: 6.0.1.Final, 7.0.0.Alpha1, 7.0.0.Final
>
>
> As the L1 requestor is registered only after the value is retrieved from data container, the (transactional) update of the value may not invalide the entry after write and the cache gets inconsistent.
> Consider this interleaving of operations (G=get request from other node, C=commit)
> R: read value -> old value
> C: update old -> new
> C: notify requestors for key
> R: add requestor for key
--
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
11 years, 12 months