[CSHARP-2868] maxIdleTimeMS implementation does not adhere to the specification Created: 09/Dec/19 Updated: 31/Mar/22 |
|
| Status: | Backlog |
| Project: | C# Driver |
| Component/s: | Connectivity |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dmitry Ryabtsev | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 2 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Not sure if this is a big issue or not, but here it is. The spec says that the default value for maxIdleTimeMS should be 0. The C# driver however does not accept 0, but throws an exception instead:
Also, maxIdleTimeMS if specified in the URI, translates into maxConnectionLifeTime, but not into maxConnectionIdleTime, which seems confusing:
The above code produces:
|
| Comments |
| Comment by Paul Fleetwood [ 14/Jul/21 ] |
|
I also ran into this disconnect with the spec, and I tried passing in a null as mentioned above, but... Timespan is a struct, and so it cannot take a null value. Trying Timespan.MaxValue also did not work because of some internal math overflow issues. I have settled on a 10,000 day timeout as a stop gap, but it seems like Timespan.Zero is the right way to specify "no timeout" given the spec. |
| Comment by Dmitry Lukyanov (Inactive) [ 13/Jan/20 ] |
|
>Correct me if I'm wrong, but I was under the impression that the whole purpose of having the drivers spec'ed so that their behaviour could be standartized. in general, it's close to true, but each driver can implement requirements not literally the same as described in the spec in case if the required spec modification arises based on the specifics of the particular language (and of course if the difference with the spec is not important and the modified spec part is not the target of the spec ticket). In this particular case, the changes are related to the fact that C# allows optional parameters, but Java doesn't allow it. cc: rstam |
| Comment by Dmitry Lukyanov (Inactive) [ 13/Dec/19 ] |
|
Hello dmitry.ryabtsev, please note, you made an error in showing results (mixed up values). If you fix it, the results in MaxConnectionLifeTime and MaxConnectionIdleTime will be expected. As for the first part of your question, it's true that we will throw the error for 0, but not sure that we need to fix it, C# allows nullable types, so the most natural way in c# to show that no limit has been specified is null. Also many .NET APIs interpret a 0 timeout NOT as "no limit" but as timeout immediately unless the operation can be completed without blocking. In order to avoid confusion we decided not to allow 0. cc: rstam, jeff.yemin
|