[
https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16198180#comment-16198180
]
stack commented on HBASE-18703:
-------------------------------
Below is a bit of a reply.
bq. Other path is very high level, generic, row processing mechanism. And is
only supposed to invoke right RowProcessors steps at right time.
Yes
bq. Other path is very high level, generic, row processing mechanism. And is
only supposed to invoke right RowProcessors steps at right time.
... all well and good but there should also be one mutation path only, not two.
bq. So if RowProcessor is more generic, shouldn't we move to it? Why move to an
option which is the limited one.
We shoudn't move to it because it is (mostly) unused, unknown (years after its
original intro), incomplete, lagging in updates, and it doesn't support CPs.
Nor do we need a generic engine at this point (we have limited API -- we'd not
be able to exploit the general facility -- and if you want more in absence of
RP, write yourself a Coprocessor Endpoint). We want a purposed code path by the
time we land inside Region. The variants are currently such that core ops in
Region are inscrutable. We can't have that.
A project to refactor sounds grand. Its all internal Private classes so could
happen anytime. Would like to start over though if we were going to do this
rather than try and hack around a bit of stale, RP code written w/ a motive now
years old.
> 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)
