[ https://issues.apache.org/jira/browse/HBASE-8336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13631451#comment-13631451 ]
Jieshan Bean commented on HBASE-8336: ------------------------------------- [~ngrigor...@gmail.com] Nice find. We encountered the same problem before. +1 on the idea of adding a flag to represent its state. > PooledHTable may be returned multiple times to the same pool > ------------------------------------------------------------ > > Key: HBASE-8336 > URL: https://issues.apache.org/jira/browse/HBASE-8336 > Project: HBase > Issue Type: Bug > Components: Client > Affects Versions: 0.95.0 > Reporter: Nikolai Grigoriev > Priority: Minor > > I have recently observed a very strange issue with an application using HBase > and HTablePool. After an investigation I have found that the root cause was > the piece of code that was calling close() twice on the same HTableInterface > instance retrieved from HTablePool (created with default policy). > A closer look at the code revealed that PooledHTable.close() calls > returnTable(), which, in turn, places the table back into the QUEUE of the > pooled tables. No checking of any kind is done so it is possible to call it > multiple times and place multiple references to the same HTable into the same > pool. > This creates a number of negative effects: > - pool grows on each close() call and eventually gets filled up with the > references to the same HTable. From this moment the pool stops working as > pool. > - multiple callers will get the same instance of HTable while expecting to > have unique instances > - once the pool is full, next call to close() will result to the call to the > real close() method of HTable. This will make HTable unusable as close() call > may shutdown() the internal thread pool. From this moment other attempts to > use this HTable will fail with RejectedExecutionException. And since the > HTablePool will have additional references to that HTable, other users of the > pool will just start failing on any call that leads to flushCommits() > The problem was, obviously, triggered by bad code on our side. But I think > the pool has to be protected. Probably the best way to fix it would be to > implement a flag in PooledHTable that represent its state (leased/returned) > and once close() is called, it would be "returned". From this moment any > operations on this PooledHTable would result in something like > IllegalStateException. -- 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