News: 1607719404

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

Buggy behavior bites .NET SqlClient, but only for those not using Windows

(2020/12/11)


Back in February, .NET software developers using Microsoft.Data.SqlClient, an open source data access driver for Microsoft SQL Server, noticed that certain queries were slow or timed out on Linux under specific circumstances.

The issue ( [1]#442 ), reported on GitHub, has lingered unfixed for almost a year now.

In July, Nerijus Arlauskas, a developer based in Lithuania, found that non-Windows clients (macOS, Linux, WSL, Docker) sometimes returned invalid results for queries, a separate but perhaps related issue ( [2]#659 ).

It's a potentially serious problem when a database provides inaccurate information. "Under no circumstances a SELECT statement should return a different result," Arlauskas [3]wrote in his report. "This can cause application crashes, personal data leaks, users purchasing products on behalf of other users, and security breaches."

Or as was said in the 1984 film Ghostbusters, "Human sacrifice, dogs and cats living together, mass hysteria!"

Fortunately, these errors occur only rarely – on systems running 2,000 or more concurrent connections, among other qualifying conditions – but that makes the root cause harder to diagnose and repair.

About a month ago, Cheena Malhotra, lead developer at US-based Magnitude Software, submitted [4]a pull request that addresses various other bugs arising from asynchronous operations interfering with one another. The changes have been merged into the SqlClient codebase but they haven't resolved issues #442 and #659.

Issue #442 has been causing problems since well before it was reported in February. In his writeup earlier this year, Pawel Pabich, engineering manager at Octopus Cloud in Brisbane, Australia, said, "We've been battling this issue for a long time now so we are happy to help in any way we can to get it resolved."

Pabich explained that Octopus Cloud hosts Octopus Deploy instances in Linux containers on Azure AKS with data stored in Azure Files and Azure SQL. Several months prior to his February post, he said, the company noticed some SQL queries were slow or timing out, which is not anything the company had seen before on Windows under the .NET framework. He suggested the SqlClient might have something to do with this.

This bug is vexing enough that developers like Samm Desmond, co-founder of blockchain biz Nodesmith and a software engineer at Shelf Engine, wrote in [5]a comment on Wednesday, "We've been having some major problems and have started rewriting anything that touches the database to use async as [Cheena Malhotra, lead developer at US-based Magnitude Software,] recommended, but it's a massive refactor for us. ...We're also considering moving back to Windows because it sounds like that would resolve the issue here?"

A solution for Issue #659 has proven to be similarly illusive. There appears to be [6]some hope that the alterations submitted by Malhotra may work, but those changes appear to require additional review and testing before they get deployed.

To help identify the situations where things go sideways, Alessio Franceschelli, senior principal engineer at Trainline in the UK, has created a containerized simulator for the SqlClient [7]using docker-compose .

Grab a seat and some popcorn. It may be a while. ®

Get our [8]Tech Resources



[1] https://github.com/dotnet/SqlClient/issues/422

[2] https://github.com/dotnet/SqlClient/issues/659

[3] https://github.com/dotnet/SqlClient/issues/659#issue-662946284

[4] https://github.com/dotnet/SqlClient/pull/796

[5] https://github.com/dotnet/SqlClient/issues/422#issuecomment-741990414

[6] https://github.com/dotnet/SqlClient/issues/659#issuecomment-727029180

[7] https://github.com/trainline/SqlClient659

[8] https://whitepapers.theregister.com/

This is most likely nonsense so stop...

chuckufarley

...Reading now.

.NET is meant to be a replacement for Java which Sun Microsystems meant to be the ultimate middleware platform. This means that Java inherited (and thus .NET) the age old "lost in translation" problem. Has anyone coined a Law about this that I could quote? Not to my knowledge so I'll get on with it...

You cannot optimize middleware for a given OS without causing performance problems and/or security issues on the other OS(s) you are running because, well, they are different. Apples are not Pi's, Windows are not Sun Rooms, GNU is Not UNIX, AMD is not Intel, Sparc is not ARM, etc.

My best guess is that someone somewhere has added optimizations to the .NET/mono code for their given platform and this is what is coming back to byte other users of the middleware. I can understand why they did it. Middleware sucks and they went to school and got a degree in programming and all they were taught was how to write apps in middleware. They were even told that this was good thing. So what harm can come from making a good thing better if the downside only affects people who are using super computers with 1024+ threads?

That kind of usage must be waaaayyy down the line. Like, 2030 at least. We can fix it before then. If we don't get laid off...

So yeah, code review FTW.

Persons attempting to find a motive in this narrative will be prosecuted;
persons attempting to find a moral in it will be banished; persons attempting
to find a plot in it will be shot. By Order of the Author
-- Mark Twain, "The Adventures of Huckleberry Finn"