[infinispan-issues] [JBoss JIRA] (ISPN-3273) Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1

William Burns (JIRA) issues at jboss.org
Wed Oct 15 09:12:35 EDT 2014


    [ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012058#comment-13012058 ] 

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)


More information about the infinispan-issues mailing list