All geek questions in one place

Deployed code timeouts but not during debugging

I have a C # winforms application with the following important elements:

  • VS2010 SP1, .NET 3.5
  • Fluent NHibernate 1.0 (with NH 3.0, maybe this is part of the problem)
  • Deployed with ClickOnce
  • SQL Server 2008 R2 Database

I have a deployed copy installed on my computer (via ClickOnce), and I launch another copy using the VS2010 debugger side by side. This is the same code base. I just published yesterday and have not changed the code since publication.

On the same computer (again, working side by side), pointing to the same instance of SQL Server, a deployed copy of my application timed out trying to write to the database. The copy started through the debugger is recorded just fine. It is repeatable every time.

In the real world, only a couple of people report a timeout. They are in the same department, right there, in the building. They are the only ones (well, that I know). I use the same instance of SQL to debug this that they use.

All files (except .pdb) are included in the deployment for all projects in the solution.

This is a stack trace for an external exception (I don't have any internal 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 can cause this timeout in one, but not the other? It works simultaneously on the same machine (or even one after another). I even run it locally from the build \ bin \ folder without a timeout, just like through the debugger. This is only a deployed copy that creates a timeout.

UPDATE:
I was able to grab the SQL Profiler trace for the production environment, and everything gets to SQL, with the exception of the actual writing to the database, which happens in the background thread. The method that performs the save (which may consist of a combination of INSERTS and / or UPDATES) is called, as I see in the trace, the request in this method, which runs immediately before the save. Now I am working on capturing the entire exception stack.

UPDATE 2:
I finally reproduced the error in the debugger and isolated the place where the exception was thrown. The request that I mentioned above, which occurs just before saving, causes a timeout. OK, now I can fix it and move on.

The question remains, however: why was it thrown into the process that runs the release code, and not during the debugging process that runs the same code base.

+6
source share
3 answers

When you use debug mode, the request timeout is endless, but this is not the case when you run it through the published version.

If the web service is called to write to the database, increase the timeout for the request, and if not, increase the connection timeout for the database in your web.config or wherever you place your connection string.

Regards, Vinit

+1
source

I had the same problem connecting to the database.

I heard from my users that they have exactly the same exception. At first I did not know what happened.

The solution was that they did not connect their VPN keys

Relationship Adam

0
source

You mentioned writing to the database in the background thread, which makes me think that this could be a concurrency problem.

Release builds are usually optimized, so they may differ slightly from debug builds. This can cause existing concurrency problems to become a real problem. Different users have different hardware with a different number of processor cores (etc.), which again leads to minor changes in the execution order.

All this is a wild assumption, without delving deep into the code, but multithreading is often the culprit of these types of "mysterious" problems.

0
source

Source: https://habr.com/ru/post/887873/

More articles:


All Articles