tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 56804] New: Use a default validationQueryTimeout other than "forever"
Date Sat, 02 Aug 2014 17:36:53 GMT

            Bug ID: 56804
           Summary: Use a default validationQueryTimeout other than
           Product: Tomcat Modules
           Version: unspecified
          Hardware: PC
                OS: Mac OS X 10.4
            Status: NEW
          Severity: normal
          Priority: P2
         Component: jdbc-pool

Recently our pool started to always return "bad" connections throwing
"Disconnected" exception once used.
However, the pool was configured with a validationQuery, testWhileIdle and a
decent check interval. We first thought we had to wait for the PoolCleaner to
kick in and the dead connections will be evicted. Unfortunately, nothing did.
The database was working ok, no traces in the log files, no evidences of
anything... The only solution was to restart the application and everything
went back to normal.

After investigation, we suspect the validationQuery never ended probably
because the network connection was cut underneath (db admin had closed the
access to the database with "drop" firewall rules).
Unfortunately, we didn't specify a validationQueryTimeout so it was left to its
default value which is "wait forever": the PoolCleaner thread was therefore
blocked waiting for the validation that will never end.

It was clearly a bad configuration and not the pool's fault. But this
experience clearly shows a validationQueryTimeout MUST ABSOLUTELY be configured
or the pool may stop working as expected (i.e. will fail to deliver valid
We believe the pool should use a reasonable default value for the
validationQueryTimeout parameter instead of "wait forever" as it is the case
for the moment. Users not aware of the importance of this parameter will
necessarily face the same issue as us with no other solution than restarting
their application. Using a default timeout value would make the pool
ready-to-use and more likely to recover under these circumstances.

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message