hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Turner (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13415) Procedure V2 - Use nonces for double submits from client
Date Wed, 08 Apr 2015 21:37:13 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14486110#comment-14486110

Keith Turner commented on HBASE-13415:

Accumulo's FATE handles this by having the four thrift calls for submitting FATE operations.
 Its safe for a client to make each thrift call multiple times until it succeeds.  The main
difference with what proposed here is that the master generates a transaction ID instead of
a client generating a nonce.  

 * A thrift call to the Accumulo master get a new FATE transaction ID.  This creates a new
FATE transaction in zookeeper with no work to do. 
 * A thrift call to seed a fate transaction with work.  This call takes the transaction ID
and an operation (like create table). 
 * A thrift call to wait on a FATE transaction to complete.   This call takes a transaction
ID and returns any failure info.
 * A thrift call to delete the status information about a completed FATE transaction.

> Procedure V2 - Use nonces for double submits from client
> --------------------------------------------------------
>                 Key: HBASE-13415
>                 URL: https://issues.apache.org/jira/browse/HBASE-13415
>             Project: HBase
>          Issue Type: Sub-task
>          Components: master
>            Reporter: Enis Soztutar
> The client can submit a procedure, but before getting the procId back, the master might
fail. In this case, the client request will fail and the client will re-submit the request.
If 1.1 client or if there is no contention for the table lock, the time window is pretty small,
but still might happen. 
> If the proc was accepted and stored in the procedure store, a re-submit from the client
will add another procedure, which will execute after the first one. The first one will likely
succeed, and the second one will fail (for example in the case of create table, the second
one will throw TableExistsException). 
> One idea is to use client generated nonces (that we already have) to guard against these
cases. The client will submit the request with the nonce and the nonce will be saved together
with the procedure in the store. In case of a double submit, the nonce-cache is checked and
the procId of the original request is returned. 

This message was sent by Atlassian JIRA

View raw message