You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Andrew Purtell (JIRA)" <ji...@apache.org> on 2016/03/08 21:28:40 UTC

[jira] [Comment Edited] (HBASE-15417) Calls to ObserverContext#bypass in a region observer's prePut method are inconsistent

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

Andrew Purtell edited comment on HBASE-15417 at 3/8/16 8:28 PM:
----------------------------------------------------------------

bq. If every other put in the batch is also bypassed, the region observer sees none of these in its postPut method. If there is at least one other put which is not bypassed, the region observer sees all of the puts in the batch including those which were bypassed.

I think - if I understand correctly - this is because bypass isn't a per-mutation setting, it's an action taken per operation. If you call bypass() during the pre hook for an operation, further processing for the entire operation by core code will not happen, including post hooks. It wouldn't be valid, if for example iterating over a batch of puts, to make a bypass decision on one put expecting it to apply to just that one put, it will apply to the entire operation, the whole batch.

As Anoop mentioned our internals are always undergoing a fair amount of churn and refactor so we may have lost the above invariant and should double check bypass behavior is consistent. And, where we may have exceptions, the exceptions to the rule are clearly documented.


was (Author: apurtell):
bq. If every other put in the batch is also bypassed, the region observer sees none of these in its postPut method. If there is at least one other put which is not bypassed, the region observer sees all of the puts in the batch including those which were bypassed.

I think - if I understand correctly - this is because bypass isn't a per-mutation setting, it's an action taken per operation. If you call bypass() during the pre hook for an operation, further processing for the entire operation by core code will not happen, including post hooks. 

As Anoop mentioned our internals are always undergoing a fair amount of churn and refactor so we may have lost the above invariant and should double check bypass behavior is consistent. And, where we may have exceptions, the exceptions to the rule are clearly documented.

> Calls to ObserverContext#bypass in a region observer's prePut method are inconsistent
> -------------------------------------------------------------------------------------
>
>                 Key: HBASE-15417
>                 URL: https://issues.apache.org/jira/browse/HBASE-15417
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors
>            Reporter: Harry Harpham
>            Priority: Minor
>
> Calling ctx.bypass(), where ctx is the ObserverContext object passed in to the region observer's prePut method, results in some inconsistent behavior.
> If every other put in the batch is also bypassed, the region observer sees none of these in its postPut method.  If there is at least one other put which is not bypassed, the region observer sees all of the puts in the batch _including those which were bypassed_.
> The end result is that, after bypassing a put, that put may or may not end up in the region observer's postPut method.  This behavior is dependent solely on which other puts the bypassed put is batched together with.
> I tried to find existing tickets for this issue, but was unable to.  Apologies if I missed something.  The closest issues I could find were HBASE-4331 and HBASE-11503, but those didn't seem to quite hit it.
> Additionally, I threw together a quick demonstration of this issue: https://github.com/hwh33/bypass-inconsistency-demo.  You can run that demo in memory using the testing utility or against a running cluster.  I actually haven't had time to test it against a cluster though, so you may encounter bugs if running in that mode (but hopefully not!).
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)