Skip to content

Conversation

@EdColeman
Copy link
Contributor

The NamespaceIdTest and TableIdTest have been occasionally failing in github actions (and possible Jenkins runs). This change adds a retry to allow cache background clean-up occur that may be effecting the cache entry count. (It is unclear why these tests seemed to have stared failing only recently.)

@EdColeman EdColeman requested a review from ctubbsii November 24, 2023 22:25
@EdColeman EdColeman self-assigned this Nov 24, 2023
Copy link
Contributor

@ddanielr ddanielr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would there be a reason why we might want to keep the # of retries configurable?

long initialSize = cacheCount(NamespaceId.cache);
NamespaceId nsId = NamespaceId.of(namespaceString);
assertEquals(initialSize + 1, cacheCount());
assertCacheCountEquals(initialSize + 1, NamespaceId.cache);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is equivalent, then this seems simpler.

Wait.waitFor(() -> NamespaceId.cache.asMap().entrySet().stream().count() == initialSize + 1);

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The one issue with using Wait.waitFor() is that it currently is in the test module. Adding the test module causes a circular dependency error - so Wait.waitFor would need to be relocated somewhere common. The Wait.waitFor does not have junit / test dependencies, so relocating it to core should not be an issue. Was just not sure we wanted to do that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Wait.waitFor does not have junit / test dependencies, so relocating it to core should not be an issue. Was just not sure we wanted to do that.

We could just add the Wait class methods to the UtilWaitThread class...

* get the actual cache size
*/
public static long cacheCount(final Cache<?,?> cache) {
return cache.asMap().entrySet().stream().count();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return cache.asMap().entrySet().stream().count();
return cache.asMap().entrySet().size();

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The size method was explicitly avoided (as noted in the comment) because of the way guava handles size() with deleted / gc eligible entries

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh gotcha, I was thinking that applies to cache.size() as opposed to cache.asMap().entrySet().size().

received);
UtilWaitThread.sleep(delayMills);
}
assertEquals(expected, received, "expected cache entry count did not match expected");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
assertEquals(expected, received, "expected cache entry count did not match expected");
assertEquals(expected, received, "actual cache entry count did not match expected");

@EdColeman EdColeman closed this May 6, 2024
@EdColeman EdColeman deleted the fix_flakey_id_tests branch May 6, 2024 20:31
@ctubbsii ctubbsii modified the milestones: 3.1.0, 2.1.3 Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants