[
https://issues.apache.org/jira/browse/HBASE-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13626099#comment-13626099
]
Sergey Shelukhin commented on HBASE-3787:
-----------------------------------------
bq. I don't think we should bubble up this specific case to the client app
unless we have a valid use case. As long as we document the semantics, it
should be good.
Currently, the book sayeth "See Increment in HTable.", with a link to javadoc,
and javadoc says: "values of columns after the increment[/append] operation",
which is subject to interpretation (but I'd read it as "after the operation and
before any other operation").
Granted, I cannot come up with non-stretch use case for AtomicLong-like return
value semantics in HBase.
I wonder what other people here think.
Implementation would be simpler with no guarantees...
> 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.94.4, 0.95.2
> Reporter: dhruba borthakur
> Priority: Critical
> Fix For: 0.95.1
>
>
> 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
