In our current enterprise system we've been struggling to lower the poolingDataSource.acquisitionTimeout from the default 30s to some more appropriate value (1-5s).
For "classic" DataSource.getConnection() scenarios it was possible, thanks to using the IncrementPoolOnTimeoutConnectionAcquiringStrategy.
The only problem is the recovery thread, since we cannot intercept the time-out exceptions and there is no default retrying mechanisms or the possibility for using a separate connection from the regular pooled connections.
So we get:
bitronix.tm.recovery.RecoveryException: cannot start recovery on a PoolingDataSource containing an XAPool of resource dtfDataSource with 7 connection(s) (0 still available)
at bitronix.tm.resource.jdbc.PoolingDataSource.startRecovery(PoolingDataSource.java:288) ~[btm-2.1.3.jar:2.1.3]
at bitronix.tm.recovery.Recoverer.recover(Recoverer.java:258) [btm-2.1.3.jar:2.1.3]
at bitronix.tm.recovery.Recoverer.recoverAllResources(Recoverer.java:226) [btm-2.1.3.jar:2.1.3]
at bitronix.tm.recovery.Recoverer.run(Recoverer.java:142) [btm-2.1.3.jar:2.1.3]
at java.lang.Thread.run(Thread.java:662) [na:1.6.0_45]
Caused by: bitronix.tm.internal.BitronixRuntimeException: XA pool of resource dtfDataSource still empty after 1s wait time
at bitronix.tm.resource.common.XAPool.waitForConnectionInPool(XAPool.java:423) ~[btm-2.1.3.jar:2.1.3]
at bitronix.tm.resource.common.XAPool.getInPool(XAPool.java:374) ~[btm-2.1.3.jar:2.1.3]
at bitronix.tm.resource.common.XAPool.getConnectionHandle(XAPool.java:123) ~[btm-2.1.3.jar:2.1.3]
at bitronix.tm.resource.jdbc.PoolingDataSource.startRecovery(PoolingDataSource.java:284) ~[btm-2.1.3.jar:2.1.3]
... 4 common frames omitted
So, this is what we need:
Add timeoutMillis to IncrementPoolOnTimeoutConnectionAcquiringStrategy, that should check if the current connection acquiring time is grater than a threshold and attempt to grow the pool according to the remaining overflow size.
This way we could still have a large Bitronix poolingDataSource.acquisitionTimeout and grow the pool even before we get a Timeout.
The Bitronix retrying policy is actually happening in the XAPool.getConnectionHandle while(true) loop, that keeps on attempting until it hits the timeout threshold. The new strategy will allow to grow the pool size even if we managed to get a connection after 1-5s.
In our current enterprise system we've been struggling to lower the poolingDataSource.acquisitionTimeout from the default 30s to some more appropriate value (1-5s).
For "classic" DataSource.getConnection() scenarios it was possible, thanks to using the IncrementPoolOnTimeoutConnectionAcquiringStrategy.
The only problem is the recovery thread, since we cannot intercept the time-out exceptions and there is no default retrying mechanisms or the possibility for using a separate connection from the regular pooled connections.
So we get:
bitronix.tm.recovery.RecoveryException: cannot start recovery on a PoolingDataSource containing an XAPool of resource dtfDataSource with 7 connection(s) (0 still available) at bitronix.tm.resource.jdbc.PoolingDataSource.startRecovery(PoolingDataSource.java:288) ~[btm-2.1.3.jar:2.1.3] at bitronix.tm.recovery.Recoverer.recover(Recoverer.java:258) [btm-2.1.3.jar:2.1.3] at bitronix.tm.recovery.Recoverer.recoverAllResources(Recoverer.java:226) [btm-2.1.3.jar:2.1.3] at bitronix.tm.recovery.Recoverer.run(Recoverer.java:142) [btm-2.1.3.jar:2.1.3] at java.lang.Thread.run(Thread.java:662) [na:1.6.0_45] Caused by: bitronix.tm.internal.BitronixRuntimeException: XA pool of resource dtfDataSource still empty after 1s wait time at bitronix.tm.resource.common.XAPool.waitForConnectionInPool(XAPool.java:423) ~[btm-2.1.3.jar:2.1.3] at bitronix.tm.resource.common.XAPool.getInPool(XAPool.java:374) ~[btm-2.1.3.jar:2.1.3] at bitronix.tm.resource.common.XAPool.getConnectionHandle(XAPool.java:123) ~[btm-2.1.3.jar:2.1.3] at bitronix.tm.resource.jdbc.PoolingDataSource.startRecovery(PoolingDataSource.java:284) ~[btm-2.1.3.jar:2.1.3] ... 4 common frames omitted
So, this is what we need:
This way we could still have a large Bitronix poolingDataSource.acquisitionTimeout and grow the pool even before we get a Timeout.
The Bitronix retrying policy is actually happening in the XAPool.getConnectionHandle while(true) loop, that keeps on attempting until it hits the timeout threshold. The new strategy will allow to grow the pool size even if we managed to get a connection after 1-5s.