c# - with - transparentnetworkipresolution
Updating.NET framework resulting in SQL timeouts (1)
I've not experienced this, but the link https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/runtime/4.0-4.7.1 indicates a change to the SQL Connection Pool, where it now retries broken connections for much longer. The link also provides a setting to bypass the new behaviour;
ConnectRetryCount = 0
Is is possible that connections in the pool are now staying alive much longer than previously as a side-effect or intended feature of this behaviour change, and therefore clogging up your connection pool with 'dead but retrying connections' whereas previously they would have died ?
Its a bit speculative; but might lead you down the right path.
We have an app which targets .NET 4.5.1, and this has remained unchanged.
However when we upgraded the .NET framework on the server from 4.5.1 -> 4.7.1, we started experiencing SQL timeouts several hours afterwards (the app target remained at 4.5.1).
"Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached."
Other servers which had the same treatment produced the issue also, so we looked for a breaking change in .NET, and found this article: https://blogs.msdn.microsoft.com/dataaccesstechnologies/2016/05/07/connection-timeout-issue-with-net-framework-4-6-1-transparentnetworkipresolution/
That article quotes a different exception type, but might be somewhat related. However I'd be stunned if our DNS lookup took longer than 500ms. Also I'd expect to see far more cases of this connection string config reported and used.
Our app is high traffic, but we're confident we're not leaking connections as this has never been an issues for years until we updated the .NET framework.
We're going to try applying this fix (and wait >24 hours to see the results), but is there anything else we could have missed? We're not confident this is the solution.
EDIT: Even after rolling .NET back to 4.5.1 and restart all servers, we're still seeing the problem. Nothing else has changed in the codebase, but we've yet to roll back a registry change which enabled 'SchUseStrongCrypto' - if that could be the cause?