[JAVA-499] Add support for connection validation Created: 27/Dec/11  Updated: 06/Apr/23  Resolved: 25/Nov/15

Status: Closed
Project: Java Driver
Component/s: Connection Management
Affects Version/s: 2.6.5
Fix Version/s: None

Type: New Feature Priority: Major - P3
Reporter: Bryon Ross Assignee: Unassigned
Resolution: Won't Fix Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File MongoPoolTest.java    
Issue Links:
Depends
Duplicate
is duplicated by JAVA-466 Connection reset by peer: socket writ... Closed
Related
related to JAVA-710 Support max connection idle time and ... Closed

 Description   

The Java MongoDB driver has a built-in connection pool. One of the downsides of a connection pool is that pooled connections may become stale or broken over time (oftentimes due to timeouts, network issues, etc.). As a result, many connection pooling implementations offer a mechanism by which pooled connections can be automatically validated (usually before use, after use, or periodically). Some examples include DBCP's validationQuery and c3p0's connection testing. It would be great if the Java MongoDB driver could also support for some means of connection validation. Such a feature need not be as complex or general as in the above implementations. For example, while arbitrary validation queries might be desirable in some cases, something as simple as a ping command seems like it would be sufficient to validate a connection in many cases.

Test case:
I've attached a rather contrived example which illustrates a case in which connection validation might be useful. To simulate connection failure, the test involves restarting mongod during a brief waiting period between two successive calls to MongoDB. The connection pool size is set to 1 to ensure that the pooled connection is used for the second call.



 Comments   
Comment by Jeffrey Yemin [ 25/Jun/13 ]

After considering the tradeoffs, it's better to check for expired connections based on configurable maximum connection life time and idle time. Linking to JAVA-710.

Comment by Jeffrey Yemin [ 14/Feb/13 ]

There are tradeoffs involved though. If the pool tests every connection on checkout, say, by calling the mongod "ping" command on it, it means there is an extra round trip to the server for every operation. And even if it did, the socket could still go down after the ping and before the client uses it, so clients can not be totally insulated.

That said, the connection pool could do more to minimize the likelihood of this happening by implementing max-time-in-pool and check-idle. But it will never be eliminated, so clients have to be prepared to deal with failures anyway.

Comment by Christian Tonhäuser [ 14/Feb/13 ]

When using the java-driver, a developer shouldn't ever have to bother with connection problems/handling, i.e. the java driver should never hand out a stale connection for use by the client OR if it does, it should at least make sure to catch (and retry) any error conditions that can arise from a stale connection instead of letting the developer handling everything.

Also, the example given by Bryon isn't that far fetched imho. In larger clusters, nodes tend to need restarts from time to time which in turn causes massive connection problems on the client side that all need to be handled in the application's code.

Therefore +1 vote for this...

Generated at Thu Feb 08 08:52:26 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.