[ 
https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17119624#comment-17119624
 ] 

ASF subversion and git services commented on GEODE-8127:
--------------------------------------------------------

Commit 343e114935fad6a78628a57b948cdd08ee0751d9 in geode's branch 
refs/heads/develop from John Hutchison
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=343e114 ]

GEODE-8127: Reintroduces changes that account for primary bucket changing 
(#5179)

* flaky test ignored

Co-authored-by: john Hutchison <hutchiso...@vmware.com>
Co-authored-by: Jens Deppe <jde...@pivotal.io>

> redis function+delta may not always execute function on primary
> ---------------------------------------------------------------
>
>                 Key: GEODE-8127
>                 URL: https://issues.apache.org/jira/browse/GEODE-8127
>             Project: Geode
>          Issue Type: Bug
>          Components: redis
>            Reporter: Darrel Schneider
>            Assignee: Jens Deppe
>            Priority: Major
>
> The redis use of regions depends on the code that will modify the region that 
> is storing redis data, to always execute on the primary. It thought it was 
> accomplishing this by marking the function as "optimizeForWrite=true" and by 
> routing the function to the node with the bucket using "withFilter(key)". 
> This works most of the time. But in some cases the function executes on a 
> redundant copy. It looks like what is happening is that at the time the 
> function is dispatched it has one idea of who the primary is and sends the 
> function to that node. But before it executes the primary moves from this 
> node to another that is doing redundancy recovery. Then when our function 
> finally does a "put" on the localDataSet it ends up being a remote operation 
> that is sent to the other node.
> If our redis function could get a lock that prevents the bucket primary 
> status from changing (see BucketRegion doLockForPrimary) and then check to 
> see if we are the primary (if not throw an exception that causes the function 
> sender to retry  (see BucketMovedException) otherwise execute the function 
> and at the end release the lock (see BucketRegion doUnlockForPrimary).
> We could enable this with a new method added to Function (much like the 
> existing isHA and optimizeForWrite). This new method could be 
> executeOnPrimary and default to false (adding a default method to the 
> Function interface will not cause backwards compatibility issues unless a 
> current class that implements Function already had added a method named 
> "executeOnPrimary").



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to