Bug 56804 - Use a default validationQueryTimeout other than "forever"
Summary: Use a default validationQueryTimeout other than "forever"
Status: NEW
Alias: None
Product: Tomcat Modules
Classification: Unclassified
Component: jdbc-pool (show other bugs)
Version: unspecified
Hardware: PC Mac OS X 10.4
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2014-08-02 17:36 UTC by Bertrand Renuart
Modified: 2014-08-02 17:36 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Bertrand Renuart 2014-08-02 17:36:53 UTC
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 connections). 
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.