什么导致“内部连接致命错误" [英] What Causes "Internal connection fatal errors"

问题描述

我有许多 ASP.Net 网站 (.Net v3.5) 在带有 SQL 2000 数据库后端的服务器上运行.几个月来，我一直在收到看似随机的 InvalidOperationExceptions，并显示消息内部连接致命错误".有时中间有几天，而有时每天会出现多个错误.

I've got a number of ASP.Net websites (.Net v3.5) running on a server with a SQL 2000 database backend. For several months, I've been receiving seemingly random InvalidOperationExceptions with the message "Internal connection fatal error". Sometimes there's a few days in between, while other times there are multiple errors per day.

例外不仅限于一个站点，尽管它们共享业务和数据访问程序集.该错误似乎总是从 SqlClient.TdsParser.Run() 抛出.它有时是从老式的直接 SqlCommand.Execute() 调用中抛出的，而其他时候是从 Linq2Sql 代码中抛出的.

The exception is not limited to one site in particular, though they share business and data access assemblies. The error seems to always be thrown from SqlClient.TdsParser.Run(). It sometimes is thrown from old-school direct SqlCommand.Execute() calls, while other times it is thrown from Linq2Sql code.

网络人员向我保证，他们的终端没有任何错误或数据包丢失.有没有其他人经历过这种情况?会不会是驱动的问题?到目前为止，我们还无法确定此异常的具体触发因素.

I've been assured by the network guys that there are no errors or packets lost on their end. Has anyone else experienced this? Could it be a driver problem? We have been unable as of yet to pinpoint a specific trigger for this exception.

我们在 Windows Server 2003 上运行 II6.

We're running II6 on Windows Server 2003.

推荐答案

忽略这个问题几个月后，随着流量逐渐增加，它开始达到临界质量.在包括一些爬虫在内的重负载下，事情变得疯狂，这些错误不断涌现.

After a few months of ignoring this issue, it started to reach a critical mass as traffic gradually increased. Under heavy load, including some crawlers, things got crazy and these errors poured in nonstop.

通过反复试验，我们最终找到了一些 SqlCommand 或 LINQ 查询，它们的 SqlConnection 在使用后没有立即关闭.相反，通过一些源于对 LINQ 连接的误解的草率编程，DataContext 对象仅在请求结束时而不是立即被释放(并关闭连接).

Through trial and error, we eventually tracked down a handful of SqlCommand or LINQ queries whose SqlConnection wasn't closed immediately after use. Instead, through some sloppy programming originating from a misunderstanding of LINQ connections, the DataContext objects were disposed (and connections closed) only at the end of a request rather than immediately.

一旦我们重构了这些方法以立即使用 C#使用"块关闭连接(为下一个请求释放该池)，我们就不再收到错误.虽然我们仍然不知道连接池会变得如此混乱的根本原因，但我们能够停止所有此类错误.这个问题与我发布的另一个类似错误一起解决了，在这里找到:为什么我的 SqlCommand 应该是 int 时返回一个字符串?

Once we refactored these methods to immediately close the connection with a C# "using" block (freeing up that pool for the next request), we received no more errors. While we still don't know the underlying reason that a connection pool would get so mixed up, we were able to cease all errors of this type. This problem was resolved in conjunction with another similar error I posted, found here: Why is my SqlCommand returning a string when it should be an int?

这篇关于什么导致“内部连接致命错误"的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！