hbase-issues mailing list archives

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

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

Anoop Sam John commented on HBASE-16992:

bq.The main point i concern is the cells in one mutation may have different rows, because
we merge the cells returned by CP into original mutation.
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.
So the issue to be handled here is to avoid the duplicate call to recordMutationWithoutWal
(?)  We need to avoid the call before merge op.
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.

> 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
>            Reporter: ChiaPing Tsai
> {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

View raw message