4.x: Occasionally force cache cleanup in PreparedStatementCachingIT

[Bouncheck]

This integration test from time to time fails on one of its methods. Evidence points to the cache itself being the culprit, as there is no guarantee that elements will be removed right away. This leads to removal event not being fired and timing out on wait for it. Calling cache.cleanUp() seems to greatly improve stability of this test.

Fixes #476 and #477

[dkropachev]

TBH I don't understand this fix, test checks if certain events where fired, it waits 10 seconds for event to be executed.
Now, your fix is just cleaning up the cache, which have nothing to do with events test is looking for.

[Bouncheck]

TBH I don't understand this fix, test checks if certain events where fired, it waits 10 seconds for event to be executed. Now, your fix is just cleaning up the cache, which have nothing to do with events test is looking for.

The event is tied to the removal from cache.
This test sets up custom cache that on element removal executes a callback (see buildCacheRemoveCallback) that in turn fires the PreparedStatementRemovalEvent. If the cache does not perform the removal the event won't be fired either. If it's not fired the listener won't see it and trigger the latch which is part of the condition that the test is waiting on.

[dkropachev]

TBH I don't understand this fix, test checks if certain events where fired, it waits 10 seconds for event to be executed. Now, your fix is just cleaning up the cache, which have nothing to do with events test is looking for.

The event is tied to the removal from cache. This test sets up custom cache that on element removal executes a callback (see buildCacheRemoveCallback) that in turn fires the PreparedStatementRemovalEvent. If the cache does not perform the removal the event won't be fired either. If it's not fired the listener won't see it and trigger the latch which is part of the condition that the test is waiting on.

Just for the record:
We have agreed on the fact that this fix is not relevant because getCache().cleanUp() is already called.
We need to find source of this instability.
Here is what should be done:

1. Drop global root log level for this particular test
2. Swap assertions on typeChangeEventLatch and preparedStmtCacheRemoveLatch: typeChangeEventLatch should go first, it will help us to see if issue in event not arriving or in how cache works.

[Bouncheck]

Just for the record: We have agreed on the fact that this fix is not relevant because getCache().cleanUp() is already called.

In theory yes, but in practice I don't see it being called on failing runs. After adding prints it seems like this place is never reached (only when failing). Cache is capable of returning a view map of size 2 but when forced to print elements it prints nothing as if it was empty. While cache.size() is expected to be approximate I don't know if it's the same with view map.
The place where 2 prepared statements are cached is always reached.

When running with debugger the test suddenly becomes surprisingly stable, so I was not able to learn anything from that yet.

2. Swap assertions on typeChangeEventLatch and preparedStmtCacheRemoveLatch: typeChangeEventLatch should go first, it will help us to see if issue in event not arriving or in how cache works.

After the swap the test still fails on prepared statement latch.

Maybe another option is that on some runs those prepared statements get somehow garbage collected, but I was under the impression (maybe wrong) that this test avoids that.

[Bouncheck]

Marking as draft since I'm getting inconsistent results.

After creating WeakReferences to the prepared statements and running extra cache.cleanUp() after failure I do get removal callbacks with RemovalCause.COLLECTED (which means "The entry was removed automatically because its key or value was garbage-collected.") however I can still access the prepared statements under weak references.
From what I see cache should be using strong keys and weak values.
Normal removals in regular passing runs have RemovalCause.EXPLICIT.

[dkropachev]

I have made some tests, this thing happens because there are no records in the cache.
Next step would be to check how assertThat(getPreparedCacheSize(session)).isEqualTo(2) goes through.
Anyways, i think reason why it is failing is the same as at #514, i.e. stmt is not getting registered on the cache.