During a recent project, there was a requirement to migrate existing ASP.NET apps hosted on Windows to Linux Docker containers. Throughout this migration, numerous challenges arose, and a significant amount of time was dedicated to the migration process. In this post, I will outline briefly some of the key challenges that were encountered. To begin, I will address the challenge with the longest battle: multiple active result sets!
Introduction
During a recent project, there was a requirement to migrate existing ASP.NET apps hosted on Windows to Linux Docker containers. Throughout this migration, numerous challenges arose, and a significant amount of time was dedicated to the migration process. In this post, as well as in subsequent posts with similar titles, I will outline briefly some of the key challenges that were encountered. To begin, I will address the challenge with the longest battle: multiple active result sets!
TL;DR
Never enable Multiple Active Result Sets (MARS) configuration in your connection string when deploying to Linux.
Details
During the migration of one of the heavy-traffic ASP.NET Windows applications to Linux, we encountered a very unusual issue that never experienced before. It involves random occurrences of significant delays, timeouts, and even TPC resets during database operations. Among several generic exceptions, one of the most frequently received exception was:
Microsoft.Data.SqlClient.SqlException: Execution Timeout Expired.
The timeout period elapsed prior to completion of the operation or the server
is not responding.
---> System.ComponentModel.Win32Exception (258): Unknown error 258
After weeks of deployments, rollbacks, meetings with network teams, and exploring memory and TCP dumps, we came across a lifesaver GitHub issue that precisely described the problem we were facing. And guess what... the issue turned out to be the "MultipleActiveResultSets=True" setting in one of our connection strings! Miraculously, after removing the MARS setting, everything fell into place and started working seamlessly!
It appears that even if your code doesn’t use the MARS setting, you can still be affected by it on Linux deployments. Reducing the parallelism in queries didn't help either! So, the bottom line is, whenever possible, try to avoid using MARS on Linux.
Fortunately, we were able to handle the logic that relied on this setting, and the deadly battle finally came to an end. We got things working and resolved, thanks once again to the aforementioned GitHub issue and to everyone who shared their knowledge.
Have a great day!
History
- 23rd February, 2024: Initial version
