CSHARP-3662: MongoClientSettings.SocketTimeout does not work for values under 500ms on Windows for sync code #1690

sanych-sun · 2025-05-09T22:40:40Z

No description provided.

sanych-sun · 2025-05-09T22:56:03Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (ObjectDisposedException ex)
+            {
+                throw new EndOfStreamException("The connection was interrupted.", ex);


Have to catch ObjectDisposedException and throw something that will make WrapExceptionIfRequired to throw MongoConnectionException. Otherwise we will fail to re-try on connection pool closing in-use connections.

How would we ever reach this line?

Any ObjectDisposedException thrown by line 50 is discarded by line 55.

This is another code path. We could get ObjectDisposedException here when connection pool was stopped with close in-use connection option. In such case connection pool will dispose all connections.

I've re-wrote the code to avoid the confusion.

src/MongoDB.Driver/Core/Connections/TcpStreamFactory.cs

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

tests/MongoDB.Driver.Tests/Core/Connections/BinaryConnectionTests.cs

rstam · 2025-05-22T15:00:28Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (ObjectDisposedException ex)
+            {
+                throw new EndOfStreamException("The connection was interrupted.", ex);


How would we ever reach this line?

Any ObjectDisposedException thrown by line 50 is discarded by line 55.

rstam · 2025-05-22T15:06:14Z

src/MongoDB.Driver/Core/Compression/SnappyCompressor.cs

@@ -34,7 +34,7 @@ public void Compress(Stream input, Stream output)
        {
            var uncompressedSize = (int)(input.Length - input.Position);
            var uncompressedBytes = new byte[uncompressedSize]; // does not include uncompressed message headers
-            input.ReadBytes(uncompressedBytes, offset: 0, count: uncompressedSize, CancellationToken.None);
+            input.ReadBytes(uncompressedBytes, offset: 0, count: uncompressedSize, Timeout.InfiniteTimeSpan, CancellationToken.None);


Curious why this change is needed.

Because this code uses helper method that I've adjusted with new parameter, so I should pass something from here too.

Will stream.ReadTimeout still be respected by BeginRead?

As far as I understood Compress/Decompress works only with in-memory kind of streams. Not sure if timeout makes sense in such case.

rstam · 2025-05-22T15:07:39Z

src/MongoDB.Driver/Core/Connections/BinaryConnection.cs

@@ -333,14 +333,15 @@ private IByteBuffer ReceiveBuffer(CancellationToken cancellationToken)
            try
            {
                var messageSizeBytes = new byte[4];
-                _stream.ReadBytes(messageSizeBytes, 0, 4, cancellationToken);
+                var readTimeout = _stream.CanTimeout ? TimeSpan.FromMilliseconds(_stream.ReadTimeout) : Timeout.InfiniteTimeSpan;


Seems weird to be getting the readTimeout from the Stream. Shouldn't it come from settings somewhere?

Also, why do we care about _stream.CanTimeout? The new code will support timeouts on any Stream no matter what the value of _stream.CanTimeout is.

This code is inhereted/copied from the RecieveBufferAsync. I can double-check when/which streams could have CanTimeout = false.

I agree that _stream.CanTimeout seems irrelevant here.

Ok. Should I remove checking the _stream.CanTimeout for both sync and async versions? Async version used to have that check before.

Yes, I think we can ignore this now as we are doing our own timeouts.

As it was discussed offline - will keep it for now. It will be replaced by CSOT timeout on the later stages of implementation.

rstam · 2025-05-22T15:08:04Z

src/MongoDB.Driver/Core/Connections/BinaryConnection.cs

@@ -535,7 +536,8 @@ private void SendBuffer(IByteBuffer buffer, CancellationToken cancellationToken)

                try
                {
-                    _stream.WriteBytes(buffer, 0, buffer.Length, cancellationToken);
+                    var writeTimeout = _stream.CanTimeout ? TimeSpan.FromMilliseconds(_stream.WriteTimeout) : Timeout.InfiniteTimeSpan;


Similar question here as for readTimeout above.

JamesKovacs

Reasonable changes. My major concern is accessing objects after disposal, which happens in a few places. This will typically raise an ObjectDisposedException. Are these calls reversed intentionally (e.g. dispose then a further cleanup call) and if so why?

JamesKovacs · 2025-05-22T21:52:53Z

src/MongoDB.Driver/Core/Connections/TcpStreamFactory.cs

+                try
+                {
+                    socket.Dispose();
+                    socket.EndConnect(connectOperation);


Shouldn't these calls be reversed? You shouldn't be calling methods on an object after disposal.

I've removed EndConnect call. We do have to await on task returned for async code path to observe the exception. I was under impression that same logic is applicable for Begin/End approach, but it is not.

src/MongoDB.Driver/Core/Connections/TcpStreamFactory.cs

JamesKovacs · 2025-05-22T21:57:07Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+                    try
+                    {
+                        stream.Dispose();
+                        stream.EndRead(readOperation);


Same comment here about using an object after disposal.

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

sanych-sun · 2025-05-28T19:50:36Z

tests/MongoDB.Driver.Tests/Core/Misc/TaskExtensionsTests.cs

+
+namespace MongoDB.Driver.Core.Misc
+{
+    public class TaskExtensionsTests


This test collection testing our pollyfil of Task.WaitAsync for net472 and netstandard2.1. Technically it do not have to run for net6, but I decided to run it for now, to demonstrate that our implementation behave the same way as native.

BorisDog · 2025-05-28T19:57:08Z

src/MongoDB.Driver/Core/Connections/BinaryConnection.cs

@@ -333,14 +333,15 @@ private IByteBuffer ReceiveBuffer(CancellationToken cancellationToken)
            try
            {
                var messageSizeBytes = new byte[4];
-                _stream.ReadBytes(messageSizeBytes, 0, 4, cancellationToken);
+                var readTimeout = _stream.CanTimeout ? TimeSpan.FromMilliseconds(_stream.ReadTimeout) : Timeout.InfiniteTimeSpan;


I agree that _stream.CanTimeout seems irrelevant here.

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

rstam · 2025-05-28T21:50:45Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+                await HandleTaskCancellation().ConfigureAwait(false);
+                throw;
+            }
+            catch (TimeoutException)


Same comment as for ReadAsync:

catch (Exception ex) when (ex is OperationCanceledException or TimeoutException)

rstam · 2025-05-28T22:00:38Z

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

+
+        public static async Task WaitAsync(this Task task, TimeSpan timeout, CancellationToken cancellationToken)
+        {
+            ValidateTimeout(timeout);


These extension methods are nice!

But there is a subtle issue here that we may or may not want to address.

The way this is currently coded when passing an invalid timeout the exception will NOT be thrown immediately. Instead a Task will be returned and the exception will be thrown later and observed by the code that awaits the Task.

To immediately throw an exception without returning a Task requires some tricks involving an async helper method.

I leave it up to you to decide if you want to be more precise about when the exception is thrown.

For one example of how to throw an exception immediately instead of returning a Task see:

https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/[Task.cs](https://source.dot.net/#System.Private.CoreLib/src/libraries/System.Private.CoreLib/src/System/Threading/Tasks/Task.cs,2825),2825

See also:

https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions#throw-argument-validation-exceptions-synchronously

Which in turn links to:

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/exceptions/creating-and-throwing-exceptions#exceptions-in-task-returning-methods

which has an example of using a static local method to separate the sync argument checking from the async part that does the work. This looks like a nice approach.

Do you mean negative timeout by "an invalid timeout"? If so - it should throw immediately, see the ValidateTimeout method.

As per our discussion - it appears you are right. Will split the implementation as per your advice.

BorisDog · 2025-05-28T21:56:16Z

src/MongoDB.Driver/Core/Connections/BinaryConnection.cs

@@ -333,14 +333,15 @@ private IByteBuffer ReceiveBuffer(CancellationToken cancellationToken)
            try
            {
                var messageSizeBytes = new byte[4];
-                _stream.ReadBytes(messageSizeBytes, 0, 4, cancellationToken);
+                var readTimeout = _stream.CanTimeout ? TimeSpan.FromMilliseconds(_stream.ReadTimeout) : Timeout.InfiniteTimeSpan;


Yes, I think we can ignore this now as we are doing our own timeouts.

tests/MongoDB.Driver.Tests/Core/Misc/TaskExtensionsTests.cs

rstam · 2025-05-28T22:03:47Z

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

+
+        public static async Task WaitAsync(this Task task, TimeSpan timeout, CancellationToken cancellationToken)
+        {
+            ValidateTimeout(timeout);


See also:

https://learn.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions#throw-argument-validation-exceptions-synchronously

rstam · 2025-05-28T22:04:58Z

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

+
+        public static async Task WaitAsync(this Task task, TimeSpan timeout, CancellationToken cancellationToken)
+        {
+            ValidateTimeout(timeout);


Which in turn links to:

https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/exceptions/creating-and-throwing-exceptions#exceptions-in-task-returning-methods

which has an example of using a static local method to separate the sync argument checking from the async part that does the work. This looks like a nice approach.

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

rstam · 2025-05-28T22:08:35Z

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs

+            throw new TimeoutException();
+        }
+
+        private static void ValidateTimeout(TimeSpan timeout)


You can keep this name if you want, but normally we would have named a method like this EnsureTimeoutIsValid.

BorisDog

Looks good, few unresolved comments.

rstam

Code looks good.

A few very minor suggestions.

rstam · 2025-05-29T17:41:36Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (ObjectDisposedException)
+            {
+                throw new IOException("Unable to read data from the transport connection: The I/O operation has been aborted because of either a thread exit or an application request.");


Curious why we didn't just use:

new IOException()

and let .NET use the default error message.

rstam · 2025-05-29T17:43:12Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (Exception ex) when (ex is OperationCanceledException or TimeoutException)
+            {
+                // Task.WaitAsync throws OperationCanceledException in case of cancellation and TimeoutException in case of timeout


This comment is ever so slightly wrong.

Task.WaitAsync does NOT throw.

But await Task.WaitAsync might.

rstam · 2025-05-29T17:43:36Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (Exception ex) when (ex is OperationCanceledException or TimeoutException)
+            {
+                // Task.WaitAsync throws OperationCanceledException in case of cancellation and TimeoutException in case of timeout


This comment is ever so slightly wrong.

Task.WaitAsync does NOT throw.

But await Task.WaitAsync might.

rstam · 2025-05-29T17:44:37Z

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs

+            }
+            catch (ObjectDisposedException)
+            {
+                throw new IOException("Unable to read data from the transport connection: The I/O operation has been aborted because of either a thread exit or an application request.");


Curious why we didn't just use:

new IOException()

and let .NET use the default error message.

rstam

LGTM

BorisDog

LGTM!

…es under 500ms on Windows for sync code

sanych-sun requested a review from a team as a code owner May 9, 2025 22:40

sanych-sun added the bug label May 9, 2025

sanych-sun requested review from papafe, BorisDog and JamesKovacs and removed request for a team and papafe May 9, 2025 22:40

sanych-sun commented May 9, 2025

View reviewed changes

BorisDog requested a review from rstam May 20, 2025 17:20

BorisDog reviewed May 20, 2025

View reviewed changes

src/MongoDB.Driver/Core/Connections/TcpStreamFactory.cs Show resolved Hide resolved

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs Outdated Show resolved Hide resolved

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs Outdated Show resolved Hide resolved

BorisDog requested changes May 21, 2025

View reviewed changes

rstam requested changes May 22, 2025

View reviewed changes

sanych-sun requested review from BorisDog and rstam May 23, 2025 16:59

JamesKovacs requested changes May 23, 2025

View reviewed changes

BorisDog reviewed May 23, 2025

View reviewed changes

src/MongoDB.Driver/Core/Misc/StreamExtensionMethods.cs Outdated Show resolved Hide resolved

sanych-sun commented May 28, 2025

View reviewed changes

sanych-sun requested review from BorisDog and JamesKovacs May 28, 2025 19:50

BorisDog requested changes May 28, 2025

View reviewed changes

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs Outdated Show resolved Hide resolved

src/MongoDB.Driver/Core/Misc/TaskExtensions.cs Outdated Show resolved Hide resolved

rstam requested changes May 28, 2025

View reviewed changes

BorisDog requested changes May 28, 2025

View reviewed changes

rstam requested changes May 28, 2025

View reviewed changes

sanych-sun requested review from rstam and BorisDog May 28, 2025 23:21

BorisDog reviewed May 29, 2025

View reviewed changes

sanych-sun requested a review from BorisDog May 29, 2025 01:48

rstam requested changes May 29, 2025

View reviewed changes

sanych-sun requested a review from rstam May 29, 2025 17:53

rstam approved these changes May 29, 2025

View reviewed changes

BorisDog approved these changes May 29, 2025

View reviewed changes

CSHARP-3662: MongoClientSettings.SocketTimeout does not work for valu…

22c6528

…es under 500ms on Windows for sync code

sanych-sun force-pushed the csharp3662 branch from 5cfc066 to 22c6528 Compare May 29, 2025 21:16

sanych-sun merged commit b2f1180 into mongodb:main May 29, 2025
28 of 34 checks passed

sanych-sun deleted the csharp3662 branch May 29, 2025 22:46

CSHARP-3662: MongoClientSettings.SocketTimeout does not work for values under 500ms on Windows for sync code #1690

CSHARP-3662: MongoClientSettings.SocketTimeout does not work for values under 500ms on Windows for sync code #1690

Uh oh!

Conversation

sanych-sun commented May 9, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JamesKovacs left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rstam May 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

rstam May 28, 2025 •

edited

Loading

sanych-sun May 28, 2025 •

edited

Loading