Lands with #893, which is where CatalogConnectionTestCase is: it is not on master yet.
Problem
CachedConnection reads its two settings from system properties on every connect:
org.openidentityplatform.opendj.jdbc.connect.timeout — the bound of one attempt,org.openidentityplatform.opendj.jdbc.pool.timeout — the deadline of a whole borrow.
So a case that wants to assert on either has to set it, and CatalogConnectionTestCase does: every one of its ten cases saves the pair, sets what it needs, and restores it in a finally. For the length of each case the setting is the JVM's, and every borrow made anywhere in that JVM reads it.
testTheCatalogConnectGivesUpAtTheDeadlineOfABorrow holds pool.timeout=1 for about a second while it exhausts its deadline; testTheCatalogConnectTakesTheConfiguredBound and testTheCatalogConnectIsUnboundedWhereTheOperatorTurnedTheBoundOff hold it at 0. A borrow made by another class in that window computes a deadline it was never meant to have — a second, or none at all. CachedConnectionTestCase drives the real pool and pins the same pair.
Why it has not bitten
The failsafe configuration runs these classes one at a time, and both classes restore what they found. The exposure is a suite configuration away, and it is the kind that fails somewhere else entirely.
What the fix looks like
A seam for the configuration rather than a global: the two settings read through one object the tests can hand a value to — CachedConnection.getConnectTimeoutSeconds() and getPoolTimeoutSeconds() are already the single places each is read, so the change is confined to them and to their callers' visibility. The cases then pin what they need without the JVM hearing about it.
Scope
Pre-existing in shape — the connect.timeout cases of that class had it before #893 — but #893 added the pool.timeout half, which has the larger blast radius, since that property also governs poll() of the deque. Filed rather than folded into #893: the seam is a change to how this package reads its configuration, not to the round that needed the cases.
Lands with #893, which is where
CatalogConnectionTestCaseis: it is not onmasteryet.Problem
CachedConnectionreads its two settings from system properties on every connect:org.openidentityplatform.opendj.jdbc.connect.timeout— the bound of one attempt,org.openidentityplatform.opendj.jdbc.pool.timeout— the deadline of a whole borrow.So a case that wants to assert on either has to set it, and
CatalogConnectionTestCasedoes: every one of its ten cases saves the pair, sets what it needs, and restores it in afinally. For the length of each case the setting is the JVM's, and every borrow made anywhere in that JVM reads it.testTheCatalogConnectGivesUpAtTheDeadlineOfABorrowholdspool.timeout=1for about a second while it exhausts its deadline;testTheCatalogConnectTakesTheConfiguredBoundandtestTheCatalogConnectIsUnboundedWhereTheOperatorTurnedTheBoundOffhold it at0. A borrow made by another class in that window computes a deadline it was never meant to have — a second, or none at all.CachedConnectionTestCasedrives the real pool and pins the same pair.Why it has not bitten
The failsafe configuration runs these classes one at a time, and both classes restore what they found. The exposure is a suite configuration away, and it is the kind that fails somewhere else entirely.
What the fix looks like
A seam for the configuration rather than a global: the two settings read through one object the tests can hand a value to —
CachedConnection.getConnectTimeoutSeconds()andgetPoolTimeoutSeconds()are already the single places each is read, so the change is confined to them and to their callers' visibility. The cases then pin what they need without the JVM hearing about it.Scope
Pre-existing in shape — the
connect.timeoutcases of that class had it before #893 — but #893 added thepool.timeouthalf, which has the larger blast radius, since that property also governspoll()of the deque. Filed rather than folded into #893: the seam is a change to how this package reads its configuration, not to the round that needed the cases.