On 7/5/20 11:07 AM, Phil Steitz wrote:
The test looks a little off to me. I am not sure I fully understand
what it is trying to do, but I suspect that the reason that it fails
sporadically (I have seen this myself) is that to succeed it needs to
run two evictor cycles when it is set to wait for only one. I may be
wrong as I don't fully follow the intent or logic of the test.
Looks to me like what it is trying to do is:
1. Create and force initialization of a BDS with initialsize = 10,
minIdle = 5, maxIdle = 10, numTestsPerEvictionRun = 3,
timeBetweenEvictionRuns = 1000, minEvictableIdleTime = 100
2. Execute a loop whose guard I don't understand that appears to wait
for an eviction cycle to complete, waiting at least 1 second
between iterations
3. Expect to see no more than 5 idle connections.
I don't understand the search for eviction threads in the guard in 2.
Just waiting would work if what we are trying to do is to verify that
old connections are being evicted (basically duplicating tests in
[pool]). In any case, in order to get down to 5, you need to run 2
cycles, because each only visits 3. It would seem to me that to make
it succeed consistently, you need to either increase
numTestsPerEvictionRun to 5 or have it wait for two cycles.
Phil
I think I now understand the intent of the test and I think that what it
is trying to do points to what may be a [pool] bug. The post mentioned
in the PR that created this test [1] may be onto something.
It seems odd that closing a GKOP with no evictor can stop the evictor
for a different GOP, but I think it may be possible. I don't have any
more time to dig on this for now, but here is what I think may be happening:
As the OP stated in [1], the close on the GKOP for the statement pool
calls BaseGOP stopEvictor. This results in
EvictionTimer.cancel(evictor, evictorShutdownTimeoutMillis,
TimeUnit.MILLISECONDS) being called with a evictor null. This starts with
if (evictor != null) {
evictor.cancel();
}
if (executor != null && executor.getQueue().isEmpty()) {
executor.shutdown();
}
A quick look at the jdk sources for the executor makes me think it is
possible that if there is just one other evictor running and it is in
process of running a task when the test above is performed, the queue
may show as empty because it has taken the queued task, is executing it
and only re-queues afterward. That could cause the main executor to be
shut down.
To make this happen, it would be best to add some latency to eviction
tasks and have another one open and close a bunch of others with
evictors disabled concurrently. If this turns out to be correct, a
simple fix would be to just exit immediately if evictor is null (a null
evictor can't be the last one).
Phil
Phil
[1]
http://mail-archives.apache.org/mod_mbox/commons-user/202004.mbox/%3CCAD1sBYus4-j4i2Fs6dvzv_p4z0kaiu_8Yz8qUwXxTGAKp1ef1g%40mail.gmail.com%3E
On 7/5/20 6:04 AM, Gary Gregory wrote:
This must be some timing issue as the test passed on GitHub and Travis,
but, I do see one failure for that on Java 11 on GitHub.
I am guessing the test might need to be set up differently.
Gary
On Fri, Jul 3, 2020, 14:35 Robert Paschek<robert.pasc...@comm-unity.at>
wrote:
Hello,
when I'm running mvn clean test on the current master branch, testEvict
always fails with the same error.
[ERROR] Failures:
[ERROR] TestAbandonedBasicDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR] TestBasicDataSource.testEvict:946 EvictionTimer thread was
destroyed with numIdle=7(expected: less or equal than 5)
[ERROR] TestBasicManagedDataSource>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
[ERROR]
TestDataSourceXAConnectionFactory>TestBasicDataSource.testEvict:946
EvictionTimer thread was destroyed with numIdle=7(expected: less or equal
than 5)
Is there something wrong with my setup? I'm using Maven 3.6.3 with
AdoptOpenJDK 8.0.252.
Thanks for help.
Regards,
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail:dev-unsubscr...@commons.apache.org
For additional commands, e-mail:dev-h...@commons.apache.org
