Modify TestDirectoryListCacheInvalidation to fix flakiness

[agrawalreetika]

Description

Modify TestDirectoryListCacheInvalidation to fix flakiness

Motivation and Context

TestDirectoryListCacheInvalidation test was failing because caching catalog hivecached is shared with https://github.com/prestodb/presto/blob/master/presto-product-tests/src/main/java/com/facebook/presto/tests/hive/TestSymlinkTableListCaching.java So the initial existing assert https://github.com/prestodb/presto/blob/master/presto-product-tests/src/main/java/com/facebook/presto/tests/hive/TestDirectoryListCacheInvalidation.java#L45 may not be true if TestSymlinkTableListCaching is running first. Since the JMX for hitcount and misscount may already be populated as part of TestSymlinkTableListCaching

Impact

Fixes #22425

Test Plan

Contributor checklist

• Please make sure your submission complies with our development, formatting, commit message, and attribution guidelines.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.

Release Notes

== NO RELEASE NOTE ==

[tdcmeehan]

Is it ensured that the cluster under test has at most one test running against it?

[tdcmeehan]

Suggested change

	long hitCount1 = (long) result.row(0).get(0);
	long missCount1 = (long) result.row(0).get(1);
	long hitCount = (long) result.row(0).get(0);
	long missCount = (long) result.row(0).get(1);

[agrawalreetika]

Is it ensured that the cluster under test has at most one test running against it?

You mean tests where hivecached is shared they are running at time on the cluster?

[tdcmeehan]

Is it ensured that the cluster under test has at most one test running against it?

You mean tests where hivecached is shared they are running at time on the cluster?

Yes--can the query count metrics be influenced by any concurrent running queries?

[agrawalreetika]

Is it ensured that the cluster under test has at most one test running against it?

You mean tests where hivecached is shared they are running at time on the cluster?

Yes--can the query count metrics be influenced by any concurrent running queries?

I think it could. Since here hitcount, missCount variable may not hold the value incremented by 1 which was captured here in https://github.com/prestodb/presto/pull/22455/files#diff-20e1ed420a5fd877893fcaacc97f3ad50d36e5ee71771a0d828a12c29dc19525R44. Since these metrics are for overall connector.

[tdcmeehan]

@agrawalreetika does it make sense then, since these metrics may be influenced by other tests, to modify the assertions to check that the counts have updated by at least 1, instead of asserting hard equality on 1?

[agrawalreetika]

@agrawalreetika does it make sense then, since these metrics may be influenced by other tests, to modify the assertions to check that the counts have updated by at least 1, instead of asserting hard equality on 1?

@tdcmeehan That would help us in such cases for the test not to fail but it could avoid the test on the actual tests since we wouldn't know if metrics are incremented with respective tests.
What about having 2 different caching catalogs for 2 tests, though this may not be efficient I think? WDYT

Else, we can update assertions to check that the counts have updated by at least 1 as you suggested earlier. LMK

[tdcmeehan]

Having a dedicated catalog for this test actually makes a lot of sense to me.

[tdcmeehan]

Thanks @agrawalreetika!