Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 60E3C18D1B for ; Tue, 7 Jul 2015 13:57:05 +0000 (UTC) Received: (qmail 76864 invoked by uid 500); 7 Jul 2015 13:57:05 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 76815 invoked by uid 500); 7 Jul 2015 13:57:05 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 76799 invoked by uid 99); 7 Jul 2015 13:57:05 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 07 Jul 2015 13:57:05 +0000 Date: Tue, 7 Jul 2015 13:57:05 +0000 (UTC) From: "Sean Busbey (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-13415) Procedure V2 - Use nonces for double submits from client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-13415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14616736#comment-14616736 ] Sean Busbey commented on HBASE-13415: ------------------------------------- bumping priority to Blocker for 1.2 per request from [~enis]. How's this coming along? > 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 > Assignee: Stephen Yuan Jiang > Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.3.0 > > > 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 (v6.3.4#6332)