[
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)
