Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 7A049200C52 for ; Mon, 10 Apr 2017 10:57:48 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 78AB9160B99; Mon, 10 Apr 2017 08:57:48 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id C841C160B85 for ; Mon, 10 Apr 2017 10:57:47 +0200 (CEST) Received: (qmail 88993 invoked by uid 500); 10 Apr 2017 08:57:47 -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 88982 invoked by uid 99); 10 Apr 2017 08:57:46 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Apr 2017 08:57:46 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 8CA47CA6D9 for ; Mon, 10 Apr 2017 08:57:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id h7wXoDpD5NBl for ; Mon, 10 Apr 2017 08:57:44 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 9FBA95FC83 for ; Mon, 10 Apr 2017 08:57:43 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id 6B4BDE0629 for ; Mon, 10 Apr 2017 08:57:42 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 92FE624069 for ; Mon, 10 Apr 2017 08:57:41 +0000 (UTC) Date: Mon, 10 Apr 2017 08:57:41 +0000 (UTC) From: "Enis Soztutar (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17576) [C++] Implement request retry mechanism over RPC for Multi calls. MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 10 Apr 2017 08:57:48 -0000 [ https://issues.apache.org/jira/browse/HBASE-17576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15962608#comment-15962608 ] Enis Soztutar commented on HBASE-17576: --------------------------------------- bq. I believe we should take this approach instead of adding it to Response object. Please create a different issue for this and attach the patch there, and let's get it committed quickly. Please address this comment as well from before: {quote} std::vector> is already an instance of std::vector>, no? You should not need to copy the vector. {quote} - This code still returns an empty vector when it is executed: {code} + std::vector results; + caller->Call().then([caller, &results](std::unique_ptr> presults) { + for (auto itr = presults->begin(); itr != presults->end(); ++itr) { + results.push_back(std::move(*itr)); + } + return folly::unit; + }); + return results; {code} Remember that when you chain lamdba's like this to the Future object using {{then()}} method, they will not get executed when the caller returns. Thus, the results vector will only get populated asynchronously which is not what we want. - This is not a unit test as it stands. Please don't use simple_client at all. In this test, there is already a mini-cluster. Please write the data in the unit test by copying code from simple-client.cc or code from {{TEST_F(ClientTest, PutGet)}} in the same file. You may have to rebase your patch for this. {code} +TEST(Client, Gets) { {code} - for synchornizing the action2erros_ DS. This is similar to the handling done at Java API. The point of above comment was that, given the more coarse grained lock (which is the {{access_}} mutex that you have in the patch), there should not be any need for a second-level mutex. You should make it so that only 1 mutex is used for both success or error cases. Coming to the way that you use {{access_}} is also not correct. You should make it more coarse grained (for example inside OnError, etc), and it does not protect all maps that are concurrent. You should instead acquire the lock in most of the methods at the beginning, and hold the lock until the end. Also, acquire the locks at each of the lambda functions as well since those lambdas are changing the maps. Remember that the lamdas execute after the actual method returns, so by the time lambda executes, the original method who "injected" the lambda is gone (hence its mutexes are de-allocated). > [C++] Implement request retry mechanism over RPC for Multi calls. > ----------------------------------------------------------------- > > Key: HBASE-17576 > URL: https://issues.apache.org/jira/browse/HBASE-17576 > Project: HBase > Issue Type: Sub-task > Reporter: Sudeep Sunthankar > Assignee: Sudeep Sunthankar > Attachments: HBASE-17576.HBASE-14850.v1.patch, HBASE-17576.HBASE-14850.v2.patch, HBASE-17576.HBASE-14850.v3.patch, HBASE-17576.HBASE-14850.v4.patch, HBASE-17576.HBASE-14850.v5.patch, HBASE-17576.HBASE-14850.v6.patch, HBASE-17576.HBASE-14850.v7.patch, HBASE-17576.HBASE-14850.v8.patch > > > This work is based on top of HBASE-17465. Multi Calls will be based on this. -- This message was sent by Atlassian JIRA (v6.3.15#6346)