开发者

Timeouts with deployed code but not during debugging

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.


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


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


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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜