Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 19 Jun 2017 23:23:01 +0000 (UTC)
From: "Devaraj Das (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13079643.1497414190000.52832.1497914581121@Atlassian.JIRA>
In-Reply-To: <JIRA.13079643.1497414190000@Atlassian.JIRA>
References: <JIRA.13079643.1497414190000@Atlassian.JIRA> <JIRA.13079643.1497414190285@jira-lw-us.apache.org>
Subject: [jira] [Commented] (HBASE-18214) Replace the folly::AtomicHashMap
 usage in the RPC layer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 19 Jun 2017 23:23:08 -0000


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

Devaraj Das commented on HBASE-18214:
-------------------------------------

bq. Instead of  std::unique_ptr<std::shared_timed_mutex> mutex_; use std::shared_timed_mutex mutex_;
The issue is the shared_timed_mutex is (rightfully) not copyable. So one would have to define explicit copy constructors in the classes where this is used... It's not clear as to what such a copy constructor would do anyway (mutexes are fundamentally not copyable safely). Treating it as a pointer in class declarations works around such things since all the instances in question would refer to the same underlying mutex. But maybe, we should declare it to be shared_ptr as opposed to a shared_ptr. In the usecase we have, we probably will not run into issues with either anyway I guess.

> Replace the folly::AtomicHashMap usage in the RPC layer
> -------------------------------------------------------
>
>                 Key: HBASE-18214
>                 URL: https://issues.apache.org/jira/browse/HBASE-18214
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Devaraj Das
>            Assignee: Devaraj Das
>         Attachments: 18214-1-1.txt, 18214-1-2.txt
>
>
> In my tests, I saw that folly::AtomicHashMap usage is not appropriate for one, rather common use case. It'd become sort of unusable (inserts would hang) after a bunch of inserts and erases. This hashmap is used to keep track of call-Id after a connection is set up in the RPC layer (insert a call-id/msg pair when an RPC is sent, and erase the pair when the corresponding response is received). Here is a simple program that will demonstrate the issue:
> {code}
> folly::AtomicHashMap<int, int> f(100);
> int i = 0;
> while (i < 10000) {
>     try {
>       f.insert(i,100);
>       LOG(INFO) << "Inserted " << i << "  " << f.size();
>       f.erase(i);
>       LOG(INFO) << "Deleted " << i << "  " << f.size();
>       i++;
>     } catch (const std::exception &e) {
>       LOG(INFO) << "Exception " << e.what();
>       break;
>     }
> }
> {code}
> After poking around a little bit, it is indeed called out as a limitation here https://github.com/facebook/folly/blob/master/folly/docs/AtomicHashMap.md (grep for 'erase'). Proposal is to replace this with something that will fit in in the above usecase (thinking of using std::unordered_map).


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)