From testing the fix submitted with PR #340 (more context in this Discord thread), it seems like there might be a problem with logic in CustomDriver initialisation, specifically when used with Oracle JDBC driver.
See this line: CustomDriver.java:130
Intendedly, in order to prevent default first-match driver selection behavior of DriverManager, CustomDriver attempts to deregister the configured driver from DriverManager and use it directly through the delegate property.
However, in the case of OracleDriver (and perhaps others), the deregister function it provides when registering with DriverManager contains globally destructive cleanup code which prevents the class from being used again after deregistering.
Specifically, from the ojdbc17-23.26.2.0.0.jar, when this deregister function of OracleDriver.java gets called as part of CustomDriver init:
private static void deregister() {
unRegisterMBeans();
AbstractTrueCacheConnectionPools.destroyAllPools();
OracleTimeoutThreadPerVM.stopWatchdog();
ThreadedCachingBlockSource.stopBlockReleaserThread();
TimeoutInterruptHandler.stopTimer();
if (threadPool != null) {
threadPool.shutdownNow();
}
HAManager.shutdownAll();
OracleDataSource.cleanup();
TxnFailoverManagerImpl.cleanup();
TcpMultiplexer.stop();
}
The TimeoutInterruptHandler.stopTimer(); call causes the static init block of oracle.net.nt.Clock to fail on future attempts to use the OracleDriver class:
package oracle.net.nt;
public class Clock {
...
static {
if (cachedCurrentTimeMillisTaskStarted.compareAndSet(false, true)) {
TimeoutInterruptHandler.scheduleAtFixedRate(cacheCurrentTimeMillis, 0L, ACCURACY_IN_MILLIS);
}
}
}
Resulting in the following error when attempting to Start a deployed channel with Database Reader source of Oracle type (imported as Resource not part of custom-lib directory):
[2026-07-15 21:02:42.385] ERROR (com.mirth.connect.server.channel.ErrorTaskHandler:26): com.mirth.connect.donkey.server.StartException: Failed to start channel test db connection 2 (5e6adfe6-4200-4543-bfb1-01dcd7c33969).
at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:792)
at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.doDeploy(DonkeyEngineController.java:2031)
at com.mirth.connect.server.controllers.DonkeyEngineController$DeployTask.execute(DonkeyEngineController.java:1835)
at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:67)
at com.mirth.connect.server.channel.ChannelTask.call(ChannelTask.java:16)
at java.base/java.util.concurrent.FutureTask.run(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.base/java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: Could not initialize class oracle.net.nt.Clock
at oracle.net.nt.NetStatImpl.incrementBytesSent(NetStatImpl.java:80)
at oracle.net.nt.TimeoutSocketChannel.logWrite(TimeoutSocketChannel.java:887)
at oracle.net.nt.TimeoutSocketChannel.doBlockedWrite(TimeoutSocketChannel.java:833)
at oracle.net.nt.TimeoutSocketChannel.write(TimeoutSocketChannel.java:772)
at oracle.net.nt.SSLSocketChannel.writeToSocket(SSLSocketChannel.java:931)
at oracle.net.nt.SSLSocketChannel.shutdown(SSLSocketChannel.java:443)
at oracle.net.nt.SSLSocketChannel.disconnect(SSLSocketChannel.java:991)
at oracle.net.nt.TcpNTAdapter.disconnect(TcpNTAdapter.java:636)
at oracle.net.ns.NSProtocolNIO.establishConnectionAfterRefusePacket(NSProtocolNIO.java:584)
at oracle.net.ns.NSProtocolNIO.handleConnectPacketResponse(NSProtocolNIO.java:482)
at oracle.net.ns.NSProtocolNIO.negotiateConnection(NSProtocolNIO.java:287)
at oracle.net.ns.NSProtocol.connect(NSProtocol.java:369)
at oracle.jdbc.driver.T4CConnection.connectNetworkSessionProtocol(T4CConnection.java:3978)
at oracle.jdbc.driver.T4CConnection.logon(T4CConnection.java:1187)
at oracle.jdbc.driver.PhysicalConnection.connect(PhysicalConnection.java:1236)
at oracle.jdbc.driver.T4CDriverExtension.getConnection(T4CDriverExtension.java:107)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:817)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:720)
at com.mirth.connect.connectors.jdbc.CustomDriver.connect(CustomDriver.java:153)
at com.mirth.connect.connectors.jdbc.CustomDriver.connect(CustomDriver.java:148)
at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.initSelectConnection(DatabaseReceiverQuery.java:338)
at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.initConnection(DatabaseReceiverQuery.java:101)
at com.mirth.connect.connectors.jdbc.DatabaseReceiverQuery.start(DatabaseReceiverQuery.java:87)
at com.mirth.connect.connectors.jdbc.DatabaseReceiver.onStart(DatabaseReceiver.java:115)
at com.mirth.connect.donkey.server.channel.SourceConnector.start(SourceConnector.java:106)
at com.mirth.connect.donkey.server.channel.PollConnector.start(PollConnector.java:31)
at com.mirth.connect.donkey.server.channel.Channel.start(Channel.java:768)
... 8 more
Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.IllegalStateException: Timer already cancelled. [in thread "Channel DeployTask Thread on (5e6adfe6-4200-4543-bfb1-01dcd7c33969) < pool-8-thread-1"]
at java.base/java.util.Timer.sched(Unknown Source)
at java.base/java.util.Timer.scheduleAtFixedRate(Unknown Source)
at oracle.net.nt.TimeoutInterruptHandler.scheduleAtFixedRate(TimeoutInterruptHandler.java:303)
at oracle.net.nt.Clock.<clinit>(Clock.java:58)
at oracle.net.nt.NetStatImpl.incrementBytesSent(NetStatImpl.java:80)
at oracle.net.nt.TimeoutSocketChannel.logWrite(TimeoutSocketChannel.java:887)
at oracle.net.nt.TimeoutSocketChannel.doBlockedWrite(TimeoutSocketChannel.java:833)
at oracle.net.nt.TimeoutSocketChannel.write(TimeoutSocketChannel.java:772)
at oracle.net.nt.SSLSocketChannel.writeToSocket(SSLSocketChannel.java:931)
at oracle.net.nt.SSLSocketChannel.wrapHandshakeMessage(SSLSocketChannel.java:699)
at oracle.net.nt.SSLSocketChannel.doSSLHandshake(SSLSocketChannel.java:539)
at oracle.net.nt.SSLSocketChannel.write(SSLSocketChannel.java:199)
at oracle.net.ns.NIOPacket.writeToSocketChannel(NIOPacket.java:378)
at oracle.net.ns.NIOConnectPacket.writeToSocketChannel(NIOConnectPacket.java:291)
at oracle.net.ns.NSProtocolNIO.negotiateConnection(NSProtocolNIO.java:214)
... 24 more
Note that the channel could only be deployed once the fix from PR #340 is in place. Without it, channel deploy fails as documented in #338.
The simple workaround for this is to keep the driver libraries within server-lib. However, this defeats the stated purpose of CustomDriver to allow multiple different versions of the same Driver class to be used.
Is this a fundamental flaw in CustomDriver's expectation to be able to trigger driver deregistering, or could there be some straightforward way to accomodate such drivers with terminal cleanup functions?
From testing the fix submitted with PR #340 (more context in this Discord thread), it seems like there might be a problem with logic in
CustomDriverinitialisation, specifically when used with Oracle JDBC driver.See this line: CustomDriver.java:130
Intendedly, in order to prevent default first-match driver selection behavior of
DriverManager,CustomDriverattempts to deregister the configured driver fromDriverManagerand use it directly through thedelegateproperty.However, in the case of
OracleDriver(and perhaps others), the deregister function it provides when registering withDriverManagercontains globally destructive cleanup code which prevents the class from being used again after deregistering.Specifically, from the ojdbc17-23.26.2.0.0.jar, when this deregister function of OracleDriver.java gets called as part of
CustomDriverinit:The
TimeoutInterruptHandler.stopTimer();call causes the static init block of oracle.net.nt.Clock to fail on future attempts to use theOracleDriverclass:Resulting in the following error when attempting to Start a deployed channel with Database Reader source of Oracle type (imported as Resource not part of
custom-libdirectory):Note that the channel could only be deployed once the fix from PR #340 is in place. Without it, channel deploy fails as documented in #338.
The simple workaround for this is to keep the driver libraries within
server-lib. However, this defeats the stated purpose ofCustomDriverto allow multiple different versions of the same Driver class to be used.Is this a fundamental flaw in
CustomDriver's expectation to be able to trigger driver deregistering, or could there be some straightforward way to accomodate such drivers with terminal cleanup functions?