[jira] [Updated] (HBASE-16992) The usage of mutation from CP is weird.

["ChiaPing Tsai (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/HBASE-16992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ChiaPing Tsai updated HBASE-16992:
----------------------------------
    Description: 
{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 merge. 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.

  was:
{code:title=HRegion.java|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 merge. 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.


> 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 merge. 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)