
If you were logged in you would be able to see more operations.
|
|
|
Environment:
|
Linux Ubuntu 20.04 LTS. Bug found when using Hikari CP 2.4.13 together with latest stable Jaybird 4.0. Both libraries compiled for Java 7.
|
|
I use Hikari CP together with Jaybird 3. I try to upgrade Jaybird lib to 4. However it is not possible now becouse of following error:
Pool init with max 2 idle connections and 30 seconds timeout
.....
HikariConfig config = new HikariConfig();
config.setAutoCommit(false);
config.setMinimumIdle(2);
config.setMaximumPoolSize(100);
config.setIdleTimeout(30000);
connectionPool = new HikariDataSource(config);
......
When the hikari pool has more than 2 idle connections for more than 30 second then the class
com.zaxxer.hikari.pool.PoolBase
calls method
void quietlyCloseConnection(final Connection connection, final String closureReason)
{
if (connection != null) {
try {
LOGGER.debug("{} - Closing connection {}: {}", poolName, connection, closureReason);
try {
setNetworkTimeout(connection, SECONDS.toMillis(15));
}
finally {
connection.close(); // continue with the close even if setNetworkTimeout() throws
}
}
catch (Throwable e) {
LOGGER.debug("{} - Closing connection {} failed", poolName, connection, e);
}
}
}
here is first called asynchronous setNetworkTimeout(connection, SECONDS.toMillis(15));
the final product of this call is call of method setNetworkTImeout in Jaybird class FBConnection. After that the connection is immediately closed.
However, the jaybird SetNetworkTimeoutCommand is executed in another thread and in the run() method of the private static SetNetworkTimeoutCommand is call to
connection.getFbDatabase().setNetworkTimeout(timeoutMillis);
Unfortunatelly the call connection.getFbDatabase() returns null pointer (connection is already closed by the hikari CP).
The content of FBConnection with the source of error follows
@Override
public void setNetworkTimeout(Executor executor, int milliseconds) throws SQLException {
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
SQLPermission sqlPermission = new SQLPermission(PERMISSION_SET_NETWORK_TIMEOUT);
securityManager.checkPermission(sqlPermission);
}
if (executor == null) {
throw FbExceptionBuilder
.forException(JaybirdErrorCodes.jb_invalidExecutor)
.toFlatSQLException();
}
if (milliseconds < 0) {
throw FbExceptionBuilder
.forException(JaybirdErrorCodes.jb_invalidTimeout)
.toFlatSQLException();
}
checkValidity();
executor.execute(new SetNetworkTimeoutCommand(this, milliseconds));
}
private static class SetNetworkTimeoutCommand implements Runnable {
private final WeakReference<FBConnection> connectionReference;
private final int timeoutMillis;
SetNetworkTimeoutCommand(FBConnection connection, int timeoutMillis) {
connectionReference = new WeakReference<>(connection);
this.timeoutMillis = timeoutMillis;
}
@Override
public void run() {
FBConnection connection = connectionReference.get();
if (connection != null) {
try {
connection.getFbDatabase().setNetworkTimeout(timeoutMillis);
} catch (SQLException e) {
log.error("Exception during asynchronous handling of setNetworkTimeout", e);
}
}
}
}
|
Description
|
I use Hikari CP together with Jaybird 3. I try to upgrade Jaybird lib to 4. However it is not possible now becouse of following error:
Pool init with max 2 idle connections and 30 seconds timeout
.....
HikariConfig config = new HikariConfig();
config.setAutoCommit(false);
config.setMinimumIdle(2);
config.setMaximumPoolSize(100);
config.setIdleTimeout(30000);
connectionPool = new HikariDataSource(config);
......
When the hikari pool has more than 2 idle connections for more than 30 second then the class
com.zaxxer.hikari.pool.PoolBase
calls method
void quietlyCloseConnection(final Connection connection, final String closureReason)
{
if (connection != null) {
try {
LOGGER.debug("{} - Closing connection {}: {}", poolName, connection, closureReason);
try {
setNetworkTimeout(connection, SECONDS.toMillis(15));
}
finally {
connection.close(); // continue with the close even if setNetworkTimeout() throws
}
}
catch (Throwable e) {
LOGGER.debug("{} - Closing connection {} failed", poolName, connection, e);
}
}
}
here is first called asynchronous setNetworkTimeout(connection, SECONDS.toMillis(15));
the final product of this call is call of method setNetworkTImeout in Jaybird class FBConnection. After that the connection is immediately closed.
However, the jaybird SetNetworkTimeoutCommand is executed in another thread and in the run() method of the private static SetNetworkTimeoutCommand is call to
connection.getFbDatabase().setNetworkTimeout(timeoutMillis);
Unfortunatelly the call connection.getFbDatabase() returns null pointer (connection is already closed by the hikari CP).
The content of FBConnection with the source of error follows
@Override
public void setNetworkTimeout(Executor executor, int milliseconds) throws SQLException {
SecurityManager securityManager = System.getSecurityManager();
if (securityManager != null) {
SQLPermission sqlPermission = new SQLPermission(PERMISSION_SET_NETWORK_TIMEOUT);
securityManager.checkPermission(sqlPermission);
}
if (executor == null) {
throw FbExceptionBuilder
.forException(JaybirdErrorCodes.jb_invalidExecutor)
.toFlatSQLException();
}
if (milliseconds < 0) {
throw FbExceptionBuilder
.forException(JaybirdErrorCodes.jb_invalidTimeout)
.toFlatSQLException();
}
checkValidity();
executor.execute(new SetNetworkTimeoutCommand(this, milliseconds));
}
private static class SetNetworkTimeoutCommand implements Runnable {
private final WeakReference<FBConnection> connectionReference;
private final int timeoutMillis;
SetNetworkTimeoutCommand(FBConnection connection, int timeoutMillis) {
connectionReference = new WeakReference<>(connection);
this.timeoutMillis = timeoutMillis;
}
@Override
public void run() {
FBConnection connection = connectionReference.get();
if (connection != null) {
try {
connection.getFbDatabase().setNetworkTimeout(timeoutMillis);
} catch (SQLException e) {
log.error("Exception during asynchronous handling of setNetworkTimeout", e);
}
}
}
}
|
Show » |
|
It looks like I misinterpreted the JDBC specification regarding the use of the executor (and I'm not the only on that did that, eg see http://bugs.mysql.com/bug.php?id=75615). Based on this discussion on jdbc-spec-discuss http://mail.openjdk.java.net/pipermail/jdbc-spec-discuss/2017-November/000236.html (which I read and forgot long before implementing this...), the executor should not be used in this case.
I will fix this in 4.0.1.
Be aware that the exception is caught and logged, so although it will produce annoying logging, the driver will function.