[jira] [Created] (HBASE-18214) Replace the folly::AtomicHashMap usage in the RPC layer

["Devaraj Das (JIRA)" <ji...@apache.org>]

Devaraj Das created HBASE-18214:
-----------------------------------

             Summary: 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


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)