Тайм-ауты с развернутым кодом, но не во время отладки

Question

У меня есть приложение C # winforms со следующими соответствующими элементами:

• VS2010 SP1, .NET 3.5
• Свободный 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 \ без тайм-аута, как через отладчик. Тайм-аут генерирует только развернутая копия.

UPDATE:
Я смог записать трассировку SQL Profiler для производственной среды, и все получает в SQL, кроме фактической записи в базу данных, которая происходит в фоновом потоке. Метод, который выполняет сохранение (которое может состоять из комбинации INSERTS и / или UPDATES), вызывается, как я вижу в трассировке, запрос в этом методе запускается непосредственно перед выполнением сохранения. Сейчас я работаю над захватом всего стека исключений.

ОБНОВЛЕНИЕ 2:
Я наконец-то воспроизвел ошибку в отладчике и выделил, где выдается исключение. Запрос, который я упомянул выше и который выполняется непосредственно перед сохранением, вызывает тайм-аут. Это хорошо, теперь я могу это исправить и двигаться дальше.

Однако остается вопрос: почему он был брошен в процесс, выполняющий код выпуска, а не в процесс отладки, выполняющий ту же самую базу кода.

Answer 1

Когда вы используете режим отладки, время ожидания запроса бесконечно, но это не тот случай, когда вы запускаете его через опубликованную версию.

Если веб-сервису вызывают для записи в базу данных, увеличьтезапрос времени ожидания, а если нет, увеличьте время подключения для базы данных в вашем web.config или где бы вы не указали строку подключения.

С уважением, Vinit

Answer 2

Вы упоминаете запись в базу данных в фоновом потоке, что заставляет меня думать, что это может быть проблемой параллелизма (многопоточности).

Сборки релизов обычно оптимизируются, поэтому они могут выполнятьсянемного отличается от отладочной сборки.Это может привести к тому, что существующие проблемы параллелизма станут настоящей проблемой.У разных пользователей разное аппаратное обеспечение, с разным количеством ядер ЦП (и т. Д.), Что опять-таки может привести к незначительным изменениям в порядке выполнения.

Все это дикие предположения без углубления в код, но многопоточностичасто является виновником подобных «загадочных» проблем.

Answer 3

У меня была такая же проблема с подключением к базе данных.

Я слышал от моих пользователей, что у них точно такое же исключение. Сначала я не знал, что случилось.

Решение состояло в том, что они не подключили свои ключи VPN

С уважением Адам