部署代码超时，但调试期间不超时
我有一个 C# winforms 应用程序，包含以下相关项目：
- VS2010 SP1、.NET 3.5
- Fluent NHibernate 1.0（带有 NH 3.0，也许这是问题的一部分）
- 使用 ClickOnce
- SQL Server 2008 R2 数据库
部署我已将部署的副本安装在我的计算机上机（通过 ClickOnce）并通过 VS2010 调试器并行运行另一个副本。这是相同的代码库。我昨天刚刚发布，自发布以来没有更改任何代码。
在同一台计算机上（再次并行运行），指向同一个 SQL Server 实例，我的应用程序的部署副本在尝试写入数据库时超时。通过调试器启动的副本写入得很好。每次都是可重复的。
在现实世界中，只有少数人报告超时。他们在同一个部门，在大楼的同一个地方。他们是唯一的（好吧，据我所知）。我正在使用他们正在使用的相同 SQL 实例来调试它。
所有文件（.pdb 除外）都包含在解决方案中所有项目的部署中。
这是外部异常的堆栈跟踪（我还没有任何内部异常的堆栈跟踪）：
Stack Trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
at NHibernate.AdoNet.AbstractBatcher.ExecuteReader(IDbCommand cmd)
at NHibernate.Loader.Loader.GetResultSet(IDbCommand st, Boolean autoDiscoverTypes, Boolean callable, RowSelection selection, ISessionImplementor session)
at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)
什么可能导致一个超时而不是另一个超时？在同一台机器上，同时运行（甚至一个紧接着另一个）。我什至从 build\bin\ 文件夹本地运行它，没有超时，就像通过调试器一样。只有部署的副本才会产生超时。
更新：
我已经能够捕获生产环境的 SQL Profiler 跟踪，并且除了实际写入数据库（这确实发生在后台线程上）之外，所有内容都已进入 SQL。正如我在跟踪中看到的那样，执行保存的方法（可以由插入和/或更新的组合组成）被调用，该方法中的查询在保存完成之前运行。我现在正在努力捕获整个异常堆栈。
更新2：
我终于在调试器中重现了错误，并隔离了抛出异常的位置。我上面提到的在保存之前立即发生的查询导致超时。很好，现在我可以解决这个问题并继续前进。
但问题仍然存在：为什么它被抛出到运行发布代码的进程中，而不是运行完全相同的代码库的调试进程中。
I have a C# winforms application with the following relevant items:
- VS2010 SP1, .NET 3.5
- Fluent NHibernate 1.0 (with NH 3.0, maybe this is part of the issue)
- Deployed with ClickOnce
- SQL Server 2008 R2 database
I have the deployed copy installed on my machine (via ClickOnce) and am running another copy via the VS2010 debugger side-by-side. It is the same code-base. I just published yesterday and have not changed any code since publishing.
On the same machine (again, running side-by-side), pointing to the same SQL Server instance, the deployed copy of my app times out trying to write to the database. The copy started through the debugger writes just fine. This is repeatable, every time.
In the real world only a couple of people are reporting the timeout. They're in the same department, right in the same place in the building. They're the only ones (ok, that I know of). I'm using the same SQL instance to debug this that they're using.
All files (except .pdb's) are included in the deployment for all projects in the solution.
This is the stack trace for the outer exception (I don't have one for any inner exceptions yet):
Stack Trace:
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.get_MetaData()
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
at System.Data.SqlClient.SqlCommand.ExecuteDbDataReader(CommandBehavior behavior)
at System.Data.Common.DbCommand.System.Data.IDbCommand.ExecuteReader()
at NHibernate.AdoNet.AbstractBatcher.ExecuteReader(IDbCommand cmd)
at NHibernate.Loader.Loader.GetResultSet(IDbCommand st, Boolean autoDiscoverTypes, Boolean callable, RowSelection selection, ISessionImplementor session)
at NHibernate.Loader.Loader.DoQuery(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
at NHibernate.Loader.Loader.DoQueryAndInitializeNonLazyCollections(ISessionImplementor session, QueryParameters queryParameters, Boolean returnProxies)
at NHibernate.Loader.Loader.DoList(ISessionImplementor session, QueryParameters queryParameters)
What could cause that timeout in one but not the other? On the same machine, running at the same time (or even one right after the other). I've even run it locally from the build\bin\ folder with no timeout, just like through the debugger. It's only the deployed copy that produces the timeout.
UPDATE:
I've been able capture a SQL Profiler trace for the production environment and everything is getting to SQL except for the actual write to the database, which does happen on a background thread. The method that performs the save (which can consist of a combination of INSERTS and/or UPDATES) is getting called as I see in the trace a query in that method that gets run just before the save is done. I'm working on capturing the entire exception stack now.
UPDATE 2:
I've finally reproduced the error in the debugger and have isolated where the exception is being thrown. The query that I mentioned above which happens immediately before the save is causing the timeout. That's good, now I can fix that and move on.
The question remains, though: why it was thrown in a process running release code and not in a debug process running the exact same code base.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当您使用调试模式时，请求超时是无限的，但当您通过发布版本运行它时，情况并非如此。
如果调用 Web 服务来写入数据库，请增加您的请求超时，如果没有，请增加 web.config 中或您放置连接字符串的任何位置的数据库连接超时。
问候，
维尼特
When you use debugging mode, request time out is infinite but that is not the case when you are running it through published version.
If a web service is getting called to write on database, please increase your request time out and if not, increase your connection time out for database in your web.config or wherever you have put your connection string.
Regards,
Vinit
我在连接数据库时遇到了同样的问题。
我从我的用户那里听说他们有完全相同的例外。
一开始我不知道出了什么问题。
解决方案是他们没有连接 VPN 密钥
问候
亚当
I had the same problem with connection to database.
I heard from my users that they have exactly the same exception.
At the beginning I didn't know what was wrong.
The solution was that they haven't connected theirs VPN keys
Regards
Adam
您提到在后台线程中写入数据库，这让我认为这可能是并发（多线程）问题。
发布版本通常是经过优化的，这就是为什么它们的执行可能与调试版本略有不同。这可能会导致现有的并发问题成为一个实际问题。不同的用户拥有不同的硬件，具有不同数量的CPU核心（等等），同样可能导致执行顺序的微妙变化。
所有这些都是在不深入研究代码的情况下的疯狂猜测，但多线程通常是这些类型的“神秘”问题的罪魁祸首。
You mention writing to the database in a background thread, which leads me to think this might be a concurrency (multi-threading) issue somehow.
Release builds are usually optimized, which is why they might execute slightly differently from a debug build. That can cause existing concurrency issues to become an actual problem. Different users have different hardware, with different numbers of CPU cores (etc), again possibly leading to subtle changes in execution order.
All of this is a wild guess without digging deep into the code, but multi-threading is often the culprit for these types of "mysterious" problems.