hbase-issues mailing list archives

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

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

Mime
View raw message