[jira] [Commented] (PHOENIX-6733) Ref count leaked test failures

["Geoffrey Jacoby (Jira)" <ji...@apache.org>]

    [ 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)