Issue Details (XML | Word | Printable)

Key: JDBC-631
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Honza Hubeny
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Jaybird JDBC Driver

NullPointerException in private static class SetNetworkTimeoutCommand - class FBConnection file ./src/main/org/firebirdsql/jdbc/ when using HikariCP

Created: 11/Aug/20 09:34 AM   Updated: 11/Aug/20 02:38 PM
Component/s: JDBC driver
Affects Version/s: Jaybird 4
Fix Version/s: Jaybird 4.0.1, Jaybird 5

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.

 Description  « Hide
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();
connectionPool = new HikariDataSource(config);

When the hikari pool has more than 2 idle connections for more than 30 second then the class


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

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

    public void setNetworkTimeout(Executor executor, int milliseconds) throws SQLException {
        SecurityManager securityManager = System.getSecurityManager();
        if (securityManager != null) {
            SQLPermission sqlPermission = new SQLPermission(PERMISSION_SET_NETWORK_TIMEOUT);
        if (executor == null) {
            throw FbExceptionBuilder
        if (milliseconds < 0) {
            throw FbExceptionBuilder

        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;

        public void run() {
            FBConnection connection = connectionReference.get();
            if (connection != null) {
                try {
                } catch (SQLException e) {
                    log.error("Exception during asynchronous handling of setNetworkTimeout", e);

 All   Comments   Change History   Subversion Commits      Sort Order: Descending order - Click to sort in ascending order
Mark Rotteveel added a comment - 11/Aug/20 02:38 PM
Jaybird 4.0.1 has been released, see

Honza Hubeny added a comment - 11/Aug/20 11:07 AM
Thank you for the quick fix. We will wait for the new version, the exception is showed to the user in our product, therefore I reported it.

Mark Rotteveel added a comment - 11/Aug/20 10:47 AM
Implemented fix. I will see if I can release Jaybird 4.0.1 this week.

Mark Rotteveel added a comment - 11/Aug/20 10:22 AM
Thanks for reporting.
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 Based on this discussion on jdbc-spec-discuss (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.