[
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