hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ChiaPing Tsai (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16992) The usage of mutation from CP is weird.
Date Fri, 04 Nov 2016 05:50:58 GMT

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

ChiaPing Tsai commented on HBASE-16992:
---------------------------------------

bq. Pls note that the merge method merges the cell sets into a single set. There is no Mutation
change happening here. This collection of cells is what treated as a single unit of write.
So IMO there is no breaking of the Row agreement. It should be ok.

I get it. Thanks for your explanation.

bq. Also as said, we dont consider Durability from CP. We will go with same Durability as
that of the corresponding Mutations in batch. Any checks and fail needed? May be not. Pls
add some comments around code that we do this way.

There are two solutions. 
# Add some comments, remove the recordMutationWithoutWal() when merging, and just ignore the
durability from CP.
# Checks and fail if the durability is not matched.

The first solution is the eventual decision? If so, i will attach the patch asap.

> The usage of mutation from CP is weird.
> ---------------------------------------
>
>                 Key: HBASE-16992
>                 URL: https://issues.apache.org/jira/browse/HBASE-16992
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0, 1.3.0, 1.4.0
>            Reporter: ChiaPing Tsai
>            Priority: Minor
>             Fix For: 2.0.0, 1.4.0, 1.3.1
>
>
> {code:title=HRegion#doMiniBatchMutate|borderStyle=solid}
> Mutation cpMutation = cpMutations[j];
> Map<byte[], List<Cell>> cpFamilyMap = cpMutation.getFamilyCellMap();
> checkAndPrepareMutation(cpMutation, replay, cpFamilyMap, now);
>  // Acquire row locks. If not, the whole batch will fail.
> acquiredRowLocks.add(getRowLockInternal(cpMutation.getRow(), true));
> if (cpMutation.getDurability() == Durability.SKIP_WAL) {
>   recordMutationWithoutWal(cpFamilyMap);
> }
> // Returned mutations from coprocessor correspond to the Mutation at index i. We can
>  // directly add the cells from those mutations to the familyMaps of this mutation.
> mergeFamilyMaps(familyMaps[i], cpFamilyMap); // will get added to the memstore later
> {code}
> 1. Does the returned mutation from coprocessor have the same row as the corresponded
mutation? If so, the acquiredRowLocks() can be saved. If not, the corresponded mutation may
maintain the cells with different row due to mergeFamilyMaps().
> 2. Is returned mutation's durability useful? If so, we should deal with the different
durabilities before mergeFamilyMaps(). If not, the recordMutationWithoutWal can be saved.

> 3. If both the returned mutation and corresponded mutation have Durability.SKIP_WAL,
the recordMutationWithoutWal() may record the duplicate cells due to mergeFamilyMaps().
> Any comment? Thanks.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message