[
https://issues.apache.org/jira/browse/HBASE-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13570831#comment-13570831
]
Enis Soztutar commented on HBASE-3787:
--------------------------------------
+1 to doing it with nonce + WAL change + temp window for nonces to the region
in trunk. One question remains is that should we expose nonces to the client,
and whether we accept custom defined nonces. The use case is smt like this:
- Client picks up events from a reliable event queue, processes it and
increments the counter. After the increment, we release the event, so that the
queue will not schedule this again.
- In case, the client fails after increment, but before releasing the event,
the incr will happen, but the event queue will give time event to some other
client after it detects that the client failed. Then for the same event, we
will do another increment.
For the above scenario, HBase is not at fault, but without allowing the client
to provide the nonce, there is no easy solution to this.
For 0.94, let's do not retry approach. Although this still won't solve the
problem completely.
> Increment is non-idempotent but client retries RPC
> --------------------------------------------------
>
> Key: HBASE-3787
> URL: https://issues.apache.org/jira/browse/HBASE-3787
> Project: HBase
> Issue Type: Bug
> Components: Client
> Affects Versions: 0.96.0, 0.94.4
> Reporter: dhruba borthakur
> Priority: Critical
> Fix For: 0.96.0
>
>
> The HTable.increment() operation is non-idempotent. The client retries the
> increment RPC a few times (as specified by configuration) before throwing an
> error to the application. This makes it possible that the same increment call
> be applied twice at the server.
> For increment operations, is it better to use
> HConnectionManager.getRegionServerWithoutRetries()? Another option would be
> to enhance the IPC module to make the RPC server correctly identify if the
> RPC is a retry attempt and handle accordingly.
--
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
