[
https://issues.apache.org/jira/browse/PHOENIX-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17564866#comment-17564866
]
Istvan Toth commented on PHOENIX-6733:
--------------------------------------
Even in ParallelStatsDisabled tests only one IT is using a MiniCluster at the
same time.
Surefire always waits for one test to finish before starting another one.
We've struggled with Minicluster restart issues in PHOENIX-6329, and we
currently do not restart the MiniClusters, we just drop all HBase tables when
we exceed a threshold after running the IT class.
I've worked har to make sure that dropping the tables is synchronous, and we
don't start the new test untill it's finished.
I have touched the cluster restart / reset code, and the leak detection code
multiple times, but the commit times do not correlate with the breakage times.
We could look into wether the leaks correlate with the minicluster table drops.
We could also play with the surefire test execution order to see if changing
those has an effect on the leaks.
> Ref count leaked test failures
> ------------------------------
>
> Key: PHOENIX-6733
> URL: https://issues.apache.org/jira/browse/PHOENIX-6733
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 5.2.0
> Reporter: Geoffrey Jacoby
> Priority: Blocker
> Fix For: 5.2.0
>
>
> In pretty much every recent Yetus test run, some tests have flapped in the
> AfterClass teardown logic which tries to check for HBase Store reference
> resource leaks. The error message is "Ref count leaked", and some common
> suites this happens to are:
> DateTimeIT
> InListIT
> SequenceIT
> IndexToolForDeleteBeforeRebuildIT
> SpooledTmpFileDeleteIT
> I haven't had much luck trying to reproduce this locally. It's also not clear
> yet whether the root cause is an HBase error or a Phoenix one. (And if it's a
> Phoenix one, is the bug with something in Phoenix or with the resource
> check?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
