[ https://issues.apache.org/jira/browse/GEODE-8127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17114451#comment-17114451 ]
ASF subversion and git services commented on GEODE-8127: -------------------------------------------------------- Commit f243c4d99e1a223af0a3134d6a423b972195c507 in geode's branch refs/heads/develop from Darrel Schneider [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f243c4d ] Revert GEODE-8127: the test is flakey (#5153) * Revert "GEODE-8127: ensure that redis function executes on primary (#5133)" This reverts commit e0cbd78149d520f77e896426b691c217d3afcfb4. The new test added in it was failing intermittently. See: GEODE-8178 > 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 > Fix For: 1.14.0 > > > 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)