You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by xiaojian zhou <zh...@gmail.com> on 2016/01/09 08:01:02 UTC

Re: Review Request 42099: Fix for 52550 issue

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/42099/
-----------------------------------------------------------

(Updated Jan. 9, 2016, 7:01 a.m.)


Review request for geode, Bruce Schuchardt and Dan Smith.


Summary (updated)
-----------------

Fix for 52550 issue


Bugs: GEODE-774
    https://issues.apache.org/jira/browse/GEODE-774


Repository: geode


Description
-------

When a wan batch is retried, the operation will be rejected by primary bucket because it has seen it. But it will still distribute to the secondary bucket. 
Sometimes, the event could be accepted due to eventtracker timeout and clean up the recorded events. But this event does not contain a version tag and can never find its version tag in the system. 

The fix is not to distribute in this case. 

Following checking have been used in many other places:
if (event.getVersionTag() != null && event.getVersionTag().hasValidVersion())

I just introduced a few more.


Diffs
-----

  gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java f487bd5 
  gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedRegion.java 92b585a 

Diff: https://reviews.apache.org/r/42099/diff/


Testing
-------

The in-house hydra test to reproduce it. 
precheckin.
A lot of wan hydra tests.


Thanks,

xiaojian zhou


Re: Review Request 42099: Fix for 52550 issue

Posted by Dan Smith <ds...@pivotal.io>.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/42099/#review113901
-----------------------------------------------------------


I thought it was still possible to disable concurrency checks for a region. It looks like you won't distribute an update in that case? That doesn't seem right!

It would be nice to see some unit tests associated with this change that demonstrate the problem.


gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java (line 538)
<https://reviews.apache.org/r/42099/#comment174687>

    Why have a different condition statement here checking the version tag? So are saying that this cause is caused when hasSeenEvent == true, right? So why not use that condition?


- Dan Smith


On Jan. 9, 2016, 7:01 a.m., xiaojian zhou wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42099/
> -----------------------------------------------------------
> 
> (Updated Jan. 9, 2016, 7:01 a.m.)
> 
> 
> Review request for geode, Bruce Schuchardt and Dan Smith.
> 
> 
> Bugs: GEODE-774
>     https://issues.apache.org/jira/browse/GEODE-774
> 
> 
> Repository: geode
> 
> 
> Description
> -------
> 
> When a wan batch is retried, the operation will be rejected by primary bucket because it has seen it. But it will still distribute to the secondary bucket. 
> Sometimes, the event could be accepted due to eventtracker timeout and clean up the recorded events. But this event does not contain a version tag and can never find its version tag in the system. 
> 
> The fix is not to distribute in this case. 
> 
> Following checking have been used in many other places:
> if (event.getVersionTag() != null && event.getVersionTag().hasValidVersion())
> 
> I just introduced a few more.
> 
> 
> Diffs
> -----
> 
>   gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/BucketRegion.java f487bd5 
>   gemfire-core/src/main/java/com/gemstone/gemfire/internal/cache/DistributedRegion.java 92b585a 
> 
> Diff: https://reviews.apache.org/r/42099/diff/
> 
> 
> Testing
> -------
> 
> The in-house hydra test to reproduce it. 
> precheckin.
> A lot of wan hydra tests.
> 
> 
> Thanks,
> 
> xiaojian zhou
> 
>