[
https://issues.apache.org/jira/browse/HBASE-3787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13652391#comment-13652391
]
Sergey Shelukhin commented on HBASE-3787:
-----------------------------------------
{quote}
bq. ...I have added that for sequential nonces but I wonder if it's worth it
for simple nonces.{quote}
bq. What is the 'that' in above ('tricks or epic locks'?)
If you have map, by client ID, of structures (say, containing nonce hashmap),
you have to clean up parent map when the clients go away, presumably on timer.
However what if some request arrives for the client you are about to remove and
grabs it from the map, to use?
Either global R/W lock is needed that will block requests for cleanup, or, for
example, DrainBarrier in each client record, so in request code op will be
started and ended (2 interlocked ops),
and in cleanup it will "stop" client before removal. If request gets client
record and fails to start op due to cleanup it will just retry getting/creating
client record.
{quote}
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.{quote}
bq. If opaque, just uuid it? You'd still have to make a long of it.
bq. Aside: Reading, tripped over this comment on securerandom "....initialize
SecureRandom (this may be a lengthy operation)" – the lengthy operation part.
That's only done once.
bq. 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.
That is actually a deterministic value which can easily be duplicated by moving
system clock back as far as I see :)
I will resurrect the client hash generation code.
bq. 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).
Hmm... that is possible, however still leaves the client guessing with regard
to operation's success.
bq. Is the attempt at sequential ids attached here?
No.
> 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
