[
https://issues.apache.org/jira/browse/PHOENIX-6733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17562837#comment-17562837
]
Geoffrey Jacoby commented on PHOENIX-6733:
------------------------------------------
[~vjasani] [~stoty] - this appears to be because of a check introduced in
PHOENIX-5296 to insure that we don't leak scanners by checking to make sure
that store files don't have any references to them when an IT test ends.
The check fails frequently (at least a few times in all CI runs), and it always
appears to be in the ParallelStatsDisabled test runs. I don't recall ever
seeing a failure in the NeedsOwnCluster test runs. That got me thinking: the
difference between ParallelStats[Enabled|Disabled] and NeedsOwnCluster is of
course that each of the latter gets its own dedicated minicluster, but for the
former we share a minicluster between multiple IT tests.
Is this check safe to run when two IT tests are using the same minicluster at
the same time? Doesn't seem like it would be, because it's checking all store
files, not just store files of tables created in a particular IT test. Seems
like we'd either need to limit it to certain tables created in an IT test
(which is hard to do generically), or limit it to only NeedsOwnCluster IT
tests. Or have I missed something?
> 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)
