SqlConnection has a connection leak?

[davidein]

When using SqlConnection in a docker linux environment it seems to leak connections but this does not happen when I run on windows.

I have created a test project that will reproduce this: https://github.com/davidein/SqlConnectionIssue

1. Update appsettings.json with a valid connection string.
2. Run dotnet restore
3. Run the web-test.sh to start the container.
4. Open http://localhost:5000/api/values
5. Check the database connections.
6. Wait for 10 minutes.
7. Check the database connections, you should see that no connections have been closed.
8. If you refresh http://localhost:5000/api/values it will create a new connection

This seems to always create a new connection after 8-10 minutes and the old connection will just hang there unused until the container is killed. I have a web service that has accumulated 490 connections over 3 days and only one in use.

If I run @@VERSION it returns "Microsoft SQL Server 2016 (RTM-CU2) (KB3182270) - 13.0.2164.0 (X64) Sep 9 2016 20:13:26 Copyright (c) Microsoft Corporation Express Edition (64-bit) on Windows Server 2012 R2 Standard 6.3 (Build 9600: ) (Hypervisor)"

Sql scripts: SELECT DB_NAME(dbid) as DBName, COUNT(dbid) as NumberOfConnections, loginame as LoginName, program_name FROM sys.sysprocesses WHERE dbid > 0 and DB_NAME(dbid) = 'somedb' GROUP BY dbid, loginame, program_name

SELECT * FROM sys.sysprocesses WHERE dbid > 0 and DB_NAME(dbid) = 'somedb'

[saurabh500]

cc @corivera

[paalmoest]

@saurabh500 Any status or workaround on this issue ?

[davidein]

Only thing I know is you can wait until late into April for version 2.0 or use something other than MS Sql Server.

[saurabh500]

Official package updated at https://www.nuget.org/packages/System.Data.SqlClient/4.3.1

[turgayozgur]

Why the new version of System.Data.SqlClient 4.4.0 does not contain this fix?

[danmoseley]

@corivera for that question as @saurabh500 is out

[corivera]

This fix is present in every .NET Core branch 1.1.0 and above. Not sure how this was missed.

[corivera]

@turgayozgur Your Dapper issue says that 4.1.0 has the leak. Why do you say that 4.4.0 has it also?

[turgayozgur]

Dapper issue is not about my comment. I know that the leak fixed in 4.3.1. That works. Also, i am trying to say that 4.4.0 has the same leak problem. I try to use 4.4.0 package first and connection leak happen. When i update the version to 4.3.1 on my project, problem solved. Also, with dotpeek, i saw that the System.Data.SqlClient.dll(4.4.0) does not contain codes about this fix.

[corivera]

Looking around in the 4.4.0 nuget package, I can see that the netstandard2.0 version of SqlClient has the correct behavior, while the netstandard1.3 version does not. The netstandard1.3 SqlClient in the 4.3.1 package has the correct behavior.

@weshaggard Where do the netstandard1.3 versions of the DLLs in the 4.4.0 packages get pulled from?

[weshaggard]

If we aren't building them live then they get pulled from the latest stable version. It is possible that we never updated to pull from the 4.3.1 package and instead pulled them from the 4.3.0 package.

[corivera]

Fixed this issue in the 4.4.1 SqlClient package by updating its netstandard1.3 package version to 4.3.1.

[ben-foster-cko]

@corivera I just updated to 4.3.1 but I'm still seeing the following after my application sitting idle for 10 minutes:

This is a .NET Core 1.1 application running in Docker (linux).

What's the best way to ensure that the SQL Client was indeed updated - I notice that it sits in a refs folder following dotnet publish?