[
https://issues.apache.org/jira/browse/HBASE-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652248#comment-13652248
]
stack commented on HBASE-3787:
------------------------------
bq. There are some design questions on r. Perhaps we should flesh out the
design before I make any major changes.
Sounds good. Suggest doing it up in a one page doc rather than inline in issue
in a comment field because will be hard to fine otherwise.
bq. ...I have added that for sequential nonces but I wonder if it's worth it
for simple nonces.
What is the 'that' in above ('tricks or epic locks'?)
bq. Client ID, for now, will be produced from IP, process id, and thread id. It
will be hashed to 8 bytes and written into nonceGroup.
If opaque, just uuid it? You'd still have to make a long of it.
Aside: Reading, tripped over this comment on securerandom "....initialize
SecureRandom (this may be a lengthy operation)" -- the lengthy operation part.
There is also http://docs.oracle.com/javase/6/docs/api/java/rmi/server/UID.html
which would be more lightweight than uuid. Still > 64bits though.
bq. With 5 minutes we'd have something like ~400Mb of RAM for hash table, which
is not totally horrible (especially for 10k QPS ).
Agree
bq. However that relies on synchronized clocks....
Yeah. How bad is that though? Currently if a regionserver clock is out of
sync w/ master we'll reject it (IIRC). We'd do something similar for a client
that is trying to do a nonce-operation? If its mutation is outside of our
nonce-keeping window (because we dropped our server-side record, we can't be
sure it not a retry coming in outside of our bounds). Would have to > long GC
though (smile).
Is the attempt at sequential ids attached here?
Good stuff Sergey.
> 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
> Assignee: Sergey Shelukhin
> Priority: Critical
> Fix For: 0.95.1
>
> Attachments: HBASE-3787-partial.patch, HBASE-3787-v0.patch,
> HBASE-3787-v1.patch, HBASE-3787-v2.patch, HBASE-3787-v3.patch
>
>
> 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
