hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicolas Liochon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-9422) AsyncProcess and HTable will submit the same mutation twice if there is an error locating region.
Date Wed, 04 Sep 2013 17:22:53 GMT

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

Nicolas Liochon commented on HBASE-9422:

The AsyncProcess can support all type of mutations, but the HTable allows only put (that's
historical). So you won't have the issue with an increment, as the bug occurs only with the
!clearBufferOnFail, and it's a pure HTable behavior. 

As well, we don't retry within the AsyncProcess in this case: the retry is inside the getLocation,
if the getLocation fails after its internal retries, we don't retry on top of it. So increments
should be fine.

I can fix it, but I wonder if we should not depreciate clearBufferOnFail. It's really strange,
and it's expensive as we need to copy the data back.
> AsyncProcess and HTable will submit the same mutation twice if there is an error locating
> -------------------------------------------------------------------------------------------------
>                 Key: HBASE-9422
>                 URL: https://issues.apache.org/jira/browse/HBASE-9422
>             Project: HBase
>          Issue Type: Bug
>          Components: Client
>    Affects Versions: 0.98.0, 0.96.0
>            Reporter: Elliott Clark
>            Assignee: Nicolas Liochon
>            Priority: Minor
> HTable#backgroundFlushCommits calls AsyncProcess#submit
> AsyncProcess#submit tries to get the region location but doesn't remove the mutation
from the write buffer.  If it doesn't get the location the mutation is added to the error
> then HTable#backgroundFlushCommits takes all mutations from the error list and adds them
to the write buffer list.
> This should result in two references to the same mutation being in the write buffer list
twice.  It's not a big deal as two of the same mutation being executed should be ideponent
(unless the two puts are executed across ms boundaries.)

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message