[
https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin....
]
William Burns commented on ISPN-3273:
-------------------------------------
This would require sending the origin information along in the request.
Actually thinking about this more this may also affect listeners in that the origin
context is not used if the node isn't the primary owner.
Example:
N1, N2 k1 owned by N1, N2
N2 runs update k1 -> v1
N2 sends request to primary owner N1
N1 sends update back to N2 (in different context to update)
N1 updates k1 and notifies listener and says origin is not local
I would have to test the latter case but I think I have heard of issues with it before.
Note it only also affects nontx caches since tx caches send the requests to all nodes
(have to confirm).
Dist L1 owners that aren't primary don't respect
assumeOriginKeptEntryInL1
--------------------------------------------------------------------------
Key: ISPN-3273
URL:
https://issues.jboss.org/browse/ISPN-3273
Project: Infinispan
Issue Type: Bug
Components: Core
Reporter: William Burns
Assignee: William Burns
Fix For: 7.0.0.CR2
Attachments: DistSyncFuncTest.java
When a write operation occurs causing a L1 invalidation, there is a boolean to say
assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the
originating node that caused this update. This works fine for the primary owner, however
any additional backups think the origin is the primary owner and such send invalidations
to possibly the real origin.
-This affects both tx and non tx caches. Tx caches that are sync don't see the
problem since locking prevents the invalidation, however it causes an unneeded network
roundtrip which can cause delay.-
Actually this only affects non-tx caches, as tx caches send the prepare/commit directly
to the owner(s) instead of having it relayed.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)