You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Duo Zhang (Jira)" <ji...@apache.org> on 2019/12/09 01:39:06 UTC

[jira] [Deleted] (HBASE-23493) CLONE - Replace the folly::AtomicHashMap usage in the RPC layer

     [ https://issues.apache.org/jira/browse/HBASE-23493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duo Zhang deleted HBASE-23493:
------------------------------


> CLONE - Replace the folly::AtomicHashMap usage in the RPC layer
> ---------------------------------------------------------------
>
>                 Key: HBASE-23493
>                 URL: https://issues.apache.org/jira/browse/HBASE-23493
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: guanyun
>            Assignee: Devaraj Das
>            Priority: Major
>             Fix For: HBASE-14850
>
>         Attachments: 18214-1-1.txt, 18214-1-2.txt, hbase-18214_v3.patch, hbase-18214_v4.patch, hbase-18214_v5.patch
>
>
> 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
(v8.3.4#803005)