[
https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17110941#comment-17110941
]
ASF GitHub Bot commented on GEODE-8127:
---------------------------------------
dschneider-pivotal commented on pull request #5129:
URL: https://github.com/apache/geode/pull/5129#issuecomment-630647810
It looks like this branch was accidently started on my hash branch instead
of develop so it has a bunch of changes that it should not have.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> 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: Darrel Schneider
> 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)
