[JBoss JIRA] (ISPN-3646) org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines
by Vitalii Chepeliuk (JIRA)
[ https://issues.jboss.org/browse/ISPN-3646?page=com.atlassian.jira.plugin.... ]
Vitalii Chepeliuk updated ISPN-3646:
------------------------------------
Attachment: DistSyncL1PessimisticFuncTest.log.zip
Added trace log for DistSyncL1PessimisticFuncTest
> org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails on Windows machines
> ---------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3646
> URL: https://issues.jboss.org/browse/ISPN-3646
> Project: Infinispan
> Issue Type: Bug
> Components: Core API
> Affects Versions: 6.0.0.CR1
> Environment: Windows 2008R2 & Windows 2012, JDK7
> Reporter: Anna Manukyan
> Assignee: William Burns
> Labels: testsuite_stability
> Attachments: DistSyncL1PessimisticFuncTest.log.zip
>
>
> The test org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update fails constantly on windows machines with the following error:
> java.lang.AssertionError: expected:<some-new-value> but was:<some-value>
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:101)
> at org.testng.AssertJUnit.assertEquals(AssertJUnit.java:108)
> at org.infinispan.distribution.DistSyncL1PessimisticFuncTest.testWriteLockBlockingForceWriteL1Update(DistSyncL1PessimisticFuncTest.java:90)
> 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.run(FutureTask.java:262)
> 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)
--
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-3617) Inconsistent L1 in non-tx distributed cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
Radim Vansa reopened ISPN-3617:
-------------------------------
I think there's another but highly-related problem. When the L1ManagerImpl builds the invalidation address list for L1LastChanceInterceptor, it removes the node where the request originated. However, as it might execute another GET just before that (and the result was cached on the origin), the origin would just stay in requestor map but the entry would not be invalidated.
There's a notice about some kind of loop (and this is the purpose of origin being removed from the address list). Please, could you elaborate a bit more about this?
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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-3617) Inconsistent L1 in non-tx distributed cache
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3617?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3617:
-----------------------------------------------
Radim Vansa <rvansa(a)redhat.com> changed the Status of [bug 1017796|https://bugzilla.redhat.com/show_bug.cgi?id=1017796] from ON_QA to ASSIGNED
> Inconsistent L1 in non-tx distributed cache
> -------------------------------------------
>
> Key: ISPN-3617
> URL: https://issues.jboss.org/browse/ISPN-3617
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.2.7.Final
> Reporter: Radim Vansa
> Assignee: William Burns
> Labels: jdg62blocker
> Fix For: 6.0.0.CR2, 6.0.0.Final
>
>
> When the change is replicated to backup owner, it sends the InvalidateL1Command to backup owners before committing the entry in EntryWrappingInterceptor (it performs the WriteCommand in parallel with sending the invalidation commmand, but then it waits until the invalidation request gets acked. If a GET is executed between the invalidation and committing the entry, the response contains outdated result and the L1 will not be invalidated until next write operation.
--
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