Ошибка многопоточности с внутренним методом log4net, работающим в Hangfire

Я запускаю процесс с зависанием, повторяющаяся задача. Эти задачи запускаются каждую минуту и ​​обрабатывают тысячи строк из БД.

У меня они работали в моей тестовой среде гладко, пока я не добавил ведение журнала log4net внутри этих методов. Теперь log4net выдает ошибку многопоточности.

log4net:ERROR Failed to append to appender [AdoNetAppender]
System.Threading.ThreadAbortException: Thread was being aborted.
   at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken)
   at System.Threading.Monitor.Enter(Object obj, Boolean& lockTaken)
   at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent)
   at log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(LoggingEvent loggingEvent)
log4net:ERROR Exception while logging
System.Threading.ThreadAbortException: Thread was being aborted.
   at log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(LoggingEvent loggingEvent)
   at log4net.Repository.Hierarchy.Logger.CallAppenders(LoggingEvent loggingEvent)
   at log4net.Repository.Hierarchy.Logger.ForcedLog(Type callerStackBoundaryDeclaringType, Level level, Object message, Exception exception)
   at log4net.Repository.Hierarchy.Logger.Log(Type callerStackBoundaryDeclaringType, Level level, Object message, Exception exception)
log4net:ERROR Failed to append to appender [AdoNetAppender]
System.Threading.ThreadAbortException: Thread was being aborted.
   at System.Threading.Monitor.ReliableEnter(Object obj, Boolean& lockTaken)
   at System.Threading.Monitor.Enter(Object obj, Boolean& lockTaken)
   at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent)
   at log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(LoggingEvent loggingEvent)
log4net:ERROR Exception while logging
System.Threading.ThreadAbortException: Thread was being aborted.
   at log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(LoggingEvent loggingEvent)
   at log4net.Repository.Hierarchy.Logger.CallAppenders(LoggingEvent loggingEvent)
   at log4net.Repository.Hierarchy.Logger.ForcedLog(Type callerStackBoundaryDeclaringType, Level level, Object message, Exception exception)
   at log4net.Repository.Hierarchy.Logger.Log(Type callerStackBoundaryDeclaringType, Level level, Object message, Exception exception)

не совсем уверен, как это исправить?

Я читал, что для фоновых потоков вы можете установить IsBackground=true и уничтожить работника, но мне кажется, что управлять им будет в подсистеме зависания.

Меня больше беспокоит исправление этого из log4net или написание метода по-другому. В этой заметке: это тестовый проект, но в реальной среде я не буду вызывать log4net напрямую, он будет заключен в LoggingService. Для этого теста я просто пытаюсь сделать его простым. если у меня нет выбора.


person ChampChris    schedule 25.09.2015    source источник


Ответы (1)


Я понял это, работая над чем-то другим. поэтому изначально таблицы Hangfire и таблицы журналов находились в одной базе данных вместе с таблицами из системы. Я заметил, что при тестировании несколько раз я сталкивался с ошибкой пула строк подключения. Я не очень беспокоился об этом из-за тестового кода, потому что это упрощенная версия архитектуры, которая будет на месте. В любом случае, мой тест предназначен для того, чтобы забить БД для имитации миллионов транзакций. В этом тестировании я понял, что для облегчения некоторых из этих проблем я должен переместить Hangfire в свою БД, что сэкономит строки подключения, а также перенесет часть этой работы с БД, при этом я мог бы также перенести ведение журнала в свою БД, что снова сохранит строку подключения в пуле.

Я говорю, что наткнулся на это, потому что я не думал о регистрации, когда решил это сделать. поэтому, когда я снова запустил свой тестовый код, я решил раскомментировать мою прямую регистрацию в методах, которые выполняет Hangfire, и это сработало так, как я изначально планировал, когда задавал вопрос.

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

person ChampChris    schedule 28.09.2015