Bug 56804

Summary: Use a default validationQueryTimeout other than "forever"
Product: Tomcat Modules Reporter: Bertrand Renuart <brenuart>
Component: jdbc-poolAssignee: Tomcat Developers Mailing List <dev>
Status: NEW ---    
Severity: normal    
Priority: P2    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X 10.4   

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.