[JAVA-4811] 'maxIdleTimeMS' is not adhering to the Mongo Docs Created: 14/Nov/22 Updated: 27/Oct/23 Resolved: 14/Nov/22 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | Connection Management |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Unknown |
| Reporter: | Namila Bandara | Assignee: | Valentin Kavalenka |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Description |
SummaryHi, Currently, I'm working on a mongo java project (Spring boot) that enables the mongo connection pooling for mongo replicates (3 replications - 1 master and 2 replicates). Here I'm using the following mongo connection string variables;
So according to this connection string, it should create a pool with min 1 connection for the replicates DB, hence the 3 connections from the application. And the definitions from Mongo Docs regarding the `maxIdleTimeMS` (Connection Pool Overview — MongoDB Manual){_}
Java driver doc;(Connection Options — Java (mongodb.com))
Specifies the maximum amount of time, in milliseconds, the Java driver will allow a pooled connection to idle before closing the connection. A value of 0 indicates that there is no upper bound on how long the driver can allow a pooled collection to be idle. According to Mongo Docs, this means there should be a connection cleaning when there is only min connection opened or if there are more connections (>3) and idle for 10s, the driver should clear all the idle connections except the min pool. From what I observed in my project, the mongo driver is clearing all the connections (even the min pool connections) and creating it again after 10s, and repeating this again and again, which will use more resources for connection creation. Please refer to the following sample logs I have collected from the application. connections 1,3,5 is the initial connections created to the replicate server. And those are killed and created again after 10s. sample logs;
Please provide the version of the driver. If applicable, please provide the MongoDB server version and topology (standalone, replica set, or sharded cluster).current mongo drivers:
Mongo Server: Replica (1 master and 2 replicates) How to ReproduceCreate a spring-boot project with the above mongo replicate connection with the above string parameters Additional Background
|
| Comments |
| Comment by Namila Bandara [ 16/Nov/22 ] | ||||||||||||||||||||||||||||||||
|
Hi Valentin, thanks for clarifying the issue. | ||||||||||||||||||||||||||||||||
| Comment by Valentin Kavalenka [ 14/Nov/22 ] | ||||||||||||||||||||||||||||||||
|
The MongoDB manual you are referring to is not fully correct in its description of the maxIdleTimeMS connection option, while being correct in a different place. You may also see that neither the driver connection guide nor the driver API restrict the effect of this option with minPoolSize. The behavior you are observing is intended, but we need to change the description of this connection option in the MongoDB manual (I filed an internal ticket for that). While the obvious use of this option is to deflate a pool, as less obvious use is to work around the behavior of some intermediary software/hardware that may detect idle TCP connections and terminate them. By setting this option to a value smaller than that used by an intermediary, a user may ensure that a pool terminates idle connections before an intermediary would have done that. If as a result of such termination the pool size drops below minPoolSize, then the pool establishes a connection replacing the terminated one (often, ASAP). This is better than a situation when an intermediary terminates a connection, as that will only be detected when trying to use the connection to execute a user operation based on the failure of the attempt. | ||||||||||||||||||||||||||||||||
| Comment by Namila Bandara [ 14/Nov/22 ] | ||||||||||||||||||||||||||||||||
|
logs:
|