3

I have created a Dockerfile for my .NET program. The program runs fine on my desktop and on an Windows Server 2016 (Azure VM) without Docker. When I try to run it inside as a container (based on microsoft/windowsservercore), then I often get database errors when connecting to my Azure SQL instances.

I have two Azure SQL instance running (P1 and no load). When a connection can be established, then they are pretty fast, but the problem is that the connection often cannot be established. It looks like the network is very unstable. These are typical errors that are thrown at me:

System.Data.SqlClient.SqlException: A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)

The inner exception reports The network path was not found. At first I thought it might be my local machine, but it also has issues on the Windows Server 2016 (with containers) VM instance in Azure.

To pinpoint the problem I have created a test program that connects to my databases every 5 seconds (and runs SELECT COUNT(*) from sysobjects). This program always succeeds to find the database.

It seems that my other program often fails during startup, but during initialization there are a lot of database calls. I suspect something is different with threading, connection pooling, ...

Anyone a clue?

Ramon de Klein
  • 5,172
  • 2
  • 41
  • 64

2 Answers2

3

We experience also more Network problems with Windows Container at the moment. But with the Software defined network like you have in Azure/Containers its general recommended to have some retry Logic in place.

If you are Using Entity Framework you can plug in a different Resiliency and Retry Strategy “SqlAzureExecutionStrategy”. This is for Azure in general not only Containers, but it can help to reduce the exceptions.

This Article describes how: https://msdn.microsoft.com/en-us/library/dn456835(v=vs.113).aspx

Serge
  • 251
  • 1
  • 8
2

It seems strange that the error message is coming from the Named Pipes Provider, because Azure SQL can only connect via TCP/IP. Somehow it seems to fall back to named pipes, which can be prevented by prefixing the hostname with tcp:. So, my connection string looks something like:

Server=tcp:example.database.windows.net;Database=<dbname>;User Id=...

This prevents the server from falling back to attempt to use named pipes and I haven't seen this issue anymore.

Unfortunately, I haven't found the cause why the named pipes provider is used in some situations. It should be caused by some configuration within the microsoft/windowsservercore image, because I have never seen the error message outside the Docker image. Otherwise, I would have suspected Azure SQL's throttling mechanism (although the load is pretty low).

Ramon de Klein
  • 5,172
  • 2
  • 41
  • 64
  • Named pipes provides is first in order of protocols which SQL tries if you did not explicitly set protocol to use. So you have to force SQL to use tcp if you want to avoid trying netpipes first. – Gregory Suvalian Jan 19 '17 at 12:46