hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Umesh Agashe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
Date Tue, 10 Oct 2017 18:47:00 GMT

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

Umesh Agashe commented on HBASE-18703:
--------------------------------------

[~appy], I can not agree with you more about RowProcessor/ processRowsWithLocks() combo being
very generic and powerful. I think calling it a RowProcessor/ processRowsWithLocks() understates
what can be done with it as processing is not only restricted to gets, puts, deletes or for
that matter rows. All this can be done with or without acquiring row locks. IMO if we decide
to retain this feature, we can consider renaming it to *ANY(Custom/ Generic etc)*Processor/
processWithOrWithoutRowsLocked() .

Concern here is:
* its exposed to user through Region APIs as a catch all solution for overcoming any current
and future limitations in HBase. See example code of CP Endpoint BaseRowProcessorEndpoint.java.
* Its not used internally except for MultiRowMutationEndpoint which can be easily removed
(add and support isAtomic() attribute to batchOp in batchMutate()).
* I also think CPs are used more compared to RPs (if any). 
* Its inscrutable which makes calling CP hooks, checking Quota enforcement almost impossible
without re-design
* Its vaguely defined feature
* There already exists a code path with more up to date fixes, code (including above mentioned).

Making batchMutate() use RowProcessor is interesting proposal but that means re-designing
and re-writing out-dated feature and moving more up-to-date code path to use it. This sounds
like difficult goal to achieve for 2.0.

> Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks
> --------------------------------------------------------------------------------------
>
>                 Key: HBASE-18703
>                 URL: https://issues.apache.org/jira/browse/HBASE-18703
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors
>            Reporter: Duo Zhang
>            Assignee: Umesh Agashe
>            Priority: Critical
>             Fix For: 2.0.0-alpha-4
>
>         Attachments: hbase-18703.master.001.patch, hbase-18703.master.002.patch, hbase-18703.master.003.patch,
hbase-18703.master.004.patch, hbase-18703.master.005.patch, hbase-18703.master.005.patch,
hbase-18703.master.005.patch, hbase-18703.master.006.patch, hbase-18703.master.007.patch
>
>
> In doMiniBatchMutate, the preBatchMutate is called before building WAL, but in processRowsWithLocks,
we suggest the RowProcessor implementation to build WAL in process  method, which is ahead
of preBatchMutate.
> If a CP modifies the mutations, especially if it removes some cells from the mutations,
then the behavior of processRowsWithLocks is broken. The changes applied to memstore and WAL
will be different. And there is no way to remove entries from a WALEdit through CP. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message