[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: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| 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: |
| 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 |
| 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... |