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.