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

Hiroshi Ikeda commented on HBASE-6651:
--------------------------------------

* I think ThreadLocalPool is useless and dangerous. You never access a content 
in ThreadLocal from other threads, and if you require information in the 
content to dispose its container object or something, you must collect the 
information by using all the thread that you ever used to access.

* RoundRobinPool might give the same object to different threads.

* It is bad to use conccurent collections. We should explictly lock larger 
sections to keep consistency, or remove synchronization concerns from PoolMap 
with using explicit locks from outside of PoolMap.

* PoolMap breaks the contract of Map; The actual behaviors of the methods of 
PoolMap are vague. Also filling out the methods of Map causes the code dirty. 
We should simplify the code by removing the needless implementation at the 
start.

                
> Thread safety of HTablePool is doubtful
> ---------------------------------------
>
>                 Key: HBASE-6651
>                 URL: https://issues.apache.org/jira/browse/HBASE-6651
>             Project: HBase
>          Issue Type: Bug
>          Components: client
>    Affects Versions: 0.94.1
>            Reporter: Hiroshi Ikeda
>            Priority: Minor
>
> There are some operations in HTablePool to access to PoolMap in multiple 
> times without any explict synchronization. 
> For example HTablePool.closeTablePool() calles PoolMap.values(), and calles 
> PoolMap.remove(). If other threads add new instances to the pool in the 
> middle of the calls, the new added instances might be dropped. 
> (HTablePool.closeTablePool() also has another problem that calling it by 
> multple threads causes accessing HTable by multiple threads.)
> Moreover, PoolMap is not thread safe for the same reason.
> For example PoolMap.put() calles ConcurrentMap.get() and calles 
> ConcurrentMap.put(). If other threads add a new instance to the concurent map 
> in the middle of the calls, the new instance might be dropped.
> And also implementations of Pool have the same problems.

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