System.ArgumentOutOfRangeException when setting IdleHttpConnectionTimeout in ClusterOptions

netcore3.1 WebApp
CouchbaseNetClient 3.2.5
I added IdleHttpConnectionTimeout to the ClusterOptions on the appsettings file for the WebApp Upon restart, the following “ArgumentOutOfRangeExceptions” were logged.

2021/12/15 12:55:35.454|INF|01c|Couchbase.Core.ClusterNode||Could not set ServicePoint properties.
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'value')
   at System.Net.ServicePoint.set_MaxIdleTime(Int32 value)
   at Couchbase.Core.IO.HTTP.UriExtensions.SetServicePointOptions(Uri uri, ClusterOptions options, ILogger logger)
2021/12/15 12:55:35.600|INF|01c|Couchbase.Core.ClusterNode||Could not set ServicePoint properties.
System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter 'value')
   at System.Net.ServicePoint.set_MaxIdleTime(Int32 value)
   at Couchbase.Core.IO.HTTP.UriExtensions.SetServicePointOptions(Uri uri, ClusterOptions options, ILogger logger)

Changed the TargetFramework to net5.0 and restarted the App. No “ArgumentOutOfRangeException” log entries. Not sure this is the correct behavior based on the comments in the CouchbaseClient SDK code.

Thanks,
T

@ticontask -

Likely a .NET version specific bug - note that .NET 5.0 uses the SocketsHttpHandler and not the ServicePointManager to set this value. What was the value you passed in?

@jmorris

The app has a TargetFramework of netcoreapp3.1, Changing the TargetFramework to net5.0 stops the errors. I thought .NET Core 3.1 used the SocketsHttpHandler also.

Thanks,
T

It does, and the code should be using that setting for .NET Core 3.1. I am curious what value were you setting ClusterOptions.IdleHttpConnectionTimeout too? The greatest value it can be set in the ServicePoint.MaxIdleTime is Int32.MaxValue.

@ticontask

I’ve been looking at this some, too, and I have a couple of clarifications that may help.

  1. SocketsHttpHandler is used by .NET Core 3.1 and later in SDK 3.2.4 and later to back HTTP connections, rather than HttpClientHandler
  2. There is a mistake in 3.2.5 targeting .NET Core 3.1 where we unnecessarily set the idle timeout on both the ServicePoint and the SocketsHttpHandler. The value on the ServicePoint should be effectively ignored, but trying to set it to an invalid value will still throw the exception you found. This is not done when targeting .NET 5, thus why you don’t see this exception there.
  3. Based on your other post, I gather that you’ve experimented with raising the value of the IdleHttpConnectionTimeout to resolve your problems. I will comment further about this on your other post.

The exception that is thrown when the value of an argument is outside the allowable range of values as defined by the invoked method. Indexing an empty list will always throw an exception. Use a method like Add to append the item to the end of the list, or Insert to place the item in the middle of the list somewhere, etc. You cannot index into a C# list if that offset doesn’t exist.

Typically, an ArgumentOutOfRangeException results from developer error. Instead of handling the exception in a try/catch block, you should eliminate the cause of the exception or, if the argument is returned by a method call or input by the user before being passed to the method that throws the exception, you should validate arguments before passing them to the method.