hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-6390) append() and increment() may result in inconsistent result on retries.
Date Fri, 13 Jul 2012 16:58:34 GMT

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

Andrew Purtell commented on HBASE-6390:

So what you are looking for here is a way for a user to, perhaps optionally, make idempotent
requests out of Append and Increment, correct?

Let me volunteer a couple of strawmen:

1) Could overload the timestamp of the Append and Increment requests. If the request is "out
of date" relative to another request already applied, throw back a DoNotRetryException (or
just a DNRE for that op if submitted as a MultiAction). This is roughly how ZooKeeper handles
this class of distributed synchronization issue. Timestamp becomes a global sequence number.
Not a logical sequence number so clocks must be closely synchronized. Each memstore would
track the (server side) time of the most recent in-place update mutation. Could go further
and keep a soft cache of in-place update times by row or even KV for use by append/increment/ICV.
If more specific information gets evicted from the cache due to pressure then fallback to
the per-memstore global timestamp would still insure correctness but potentially more resubmission
work for the client/app.

2) A more generic option could be:

  * Extend the API where the user can set an optional cookie (a long). 

  * Keep a ring buffer of recent cookies up on the server.

  * Check the buffer first if a request with given cookie has already been applied and throw
an exception back to the client if so.

Wouldn't guarantee correctness outside of some time bound. Also I worry about state management
on the server. How large would that buffer need to be to capture all cookies submitted within
~(2 * time bound)?
> append() and increment() may result in inconsistent result on retries.
> ----------------------------------------------------------------------
>                 Key: HBASE-6390
>                 URL: https://issues.apache.org/jira/browse/HBASE-6390
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.94.0, 0.96.0
>            Reporter: Ashutosh Jindal
> append() and increment() api can give inconsistent result in following scenarios :
> 1- For eg, if the client does not receive the response in the specified time, it retries.
 Now the first call to increment/append is already done and this retry will again make the
operation to succeed.  
> 2- Now if the sync() to WAL fails we get an IOException, on getting an exception there
is a retry done which again results in the doing the increment/append again.  
> When may need some sort of roll back for the second problem.
> For the first one we need to see how to handle this.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message