[
https://issues.apache.org/jira/browse/HBASE-8336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13663982#comment-13663982
]
Hadoop QA commented on HBASE-8336:
----------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12584276/HBASE-8336_2.patch
against trunk revision .
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 hadoop1.0{color}. The patch compiles against the hadoop
1.0 profile.
{color:green}+1 hadoop2.0{color}. The patch compiles against the hadoop
2.0 profile.
{color:green}+1 javadoc{color}. The javadoc tool did not generate any
warning messages.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 findbugs{color}. The patch does not introduce any new
Findbugs (version 1.3.9) warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces lines longer than
100
{color:red}-1 site{color}. The patch appears to cause mvn site goal to
fail.
{color:green}+1 core tests{color}. The patch passed unit tests in .
Test results:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-prefix-tree.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-client.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-common.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-protocol.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-server.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop1-compat.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-examples.html
Findbugs warnings:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//artifact/trunk/patchprocess/newPatchFindbugsWarningshbase-hadoop-compat.html
Console output:
https://builds.apache.org/job/PreCommit-HBASE-Build/5784//console
This message is automatically generated.
> 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
> Attachments: HBASE-8336_1.patch, HBASE-8336_2.patch
>
>
> 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
