[
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
