[
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:
-------------------------------------
[[email protected]] 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
