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

Lars Hofhansl commented on HBASE-7295:
--------------------------------------

Double checked locking is fine when the variable checked in declared volatile 
(i.e. ensure proper read/write memory barriers).
Here PoolMap itself would have to be thread-safe, which - as far as I know - it 
is not.

Also in the uncontended case an access to a volatile is not significantly 
cheaper than a synchronized statement, so I doubt that even if it was correct 
it would actually improve the situation ... Unless you see extremely high 
contention on this lock.

Do you have sample code that can reproduce the problem? Until then I'm -1 on 
this change. (sorry)

                
> Contention in HBaseClient.getConnection
> ---------------------------------------
>
>                 Key: HBASE-7295
>                 URL: https://issues.apache.org/jira/browse/HBASE-7295
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.94.3
>            Reporter: Varun Sharma
>            Assignee: Varun Sharma
>             Fix For: 0.95.0
>
>         Attachments: 7295-0.94.txt, 7295-0.94-v2.txt, 7295-0.94-v3.txt, 
> 7295-0.94-v4.txt, 7295-0.94-v5.txt, 7295-trunk.txt, 7295-trunk.txt, 
> 7295-trunk-v2.txt, 7295-trunk-v3.txt, 7295-trunk-v3.txt, 7295-trunk-v4.txt
>
>
> HBaseClient.getConnection() synchronizes on the connections object. We found 
> severe contention on a thrift gateway which was fanning out roughly 3000+ 
> calls per second to hbase region servers. The thrift gateway had 2000+ 
> threads for handling incoming connections. Threads were blocked on the 
> syncrhonized block - we set ipc.pool.size to 200. Since we are using 
> RoundRobin/ThreadLocal pool only - its not necessary to synchronize on 
> connections - it might lead to cases where we might go slightly over the 
> ipc.max.pool.size() but the additional connections would timeout after 
> maxIdleTime - underlying PoolMap connections object is thread safe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to