[
https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Umesh Agashe updated HBASE-18703:
---------------------------------
Attachment: hbase-18703.master.001.patch
Case for deprecating o.a.h.h.regionserver.RowProcessor:
Currently Region.processRowsWithLocks() API takes
o.a.h.h.regionserver.RowProcessor as an argument and only implementation of
this class is MultiRowMutationProcessor. This implementation is internal and
used from HRegion.mutateRows...() methods.
HRegion.processRowsWithLocks() implementation, doesn't call coprocessor hooks
but instead calls RowProcessor hooks at appropriate point in execution. Many of
these hooks/ methods have same names and are called at similar points during
the course of execution but they are not related!
HRegion.batchMutate() methods call coprocessor hooks but not row RowProcessor
hooks.
Internal implementation MultiRowMutationProcessor, call coprocessor hooks from
inside it's own methods/ hooks. But this can not be expected of all
implementations for RowProcessors.
In case of HRegion.batchMutate(), CP mutations are merged with input mutations
and these merged mutations are applied to WALEdit from CP.
In case of processRowsWithLocks(), mutations are fetched from RowProcessor
instance and are applied on WALEdit built by RowProcessor.
The major inconsistency here is, one code path uses coprocessors while other
uses RowProcessor. There are other minor inconsistencies along those two code
paths.
Proposed fix:
* Unify two code paths.
* Deprecate RowProcessor and API Region.processRowsWithLocks() that takes
RowProcessor as an argument.
* Provide alternate API that doesn't take RowProcessor.
* Modify batchMutate() to take additional arguments: rowsToLock and atomic
(boolean).
* Remove MultiRowMutationProcessor. Make HRegion.mutateRows() methods to use
batchMutate().
* Make new implementation of Region.processRowsWithLocks() which doesn't take
RowProcessor as an argument use batchMutate().
Attached patch 001 has partial changes intended for heads-up and testing.
> Inconsistent behavior for preBatchMutate in doMiniBatchMutate and
> processRowsWithLocks
> --------------------------------------------------------------------------------------
>
> Key: HBASE-18703
> URL: https://issues.apache.org/jira/browse/HBASE-18703
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
> Reporter: Duo Zhang
> Assignee: Umesh Agashe
> Priority: Critical
> Fix For: 2.0.0-alpha-4
>
> Attachments: hbase-18703.master.001.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)
