WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 04.03.15 22:46
Оценка: 3 (2)
Уже дважды на продакшене наблюдали полное зависание одного нашего сервиса. Сервис обрабатывает входящие сообщения (используем NServiceBus c MSMQ-транспортом, все на .Net 4.5).

  В двух словах о внутреннем устройстве NServiceBus
Запускается 64 long running-таски, в каждой таске в цикле достается очередное входящее MSMQ-сообщение, затем ищется и выполняется его обработчик.

Обработчик сообщения синхронно обращается к внешнему веб-сервису (basicHttpBinding). Контракт веб-сервиса асинхронный (Task-based), поэтому синхронный вызов делается путем myProxy.MyRemoteMethodAsync().Wait(). Все это работает как Windows Service, поэтому нет, контексты синхронизации не причем (ибо нет их).

Зависание выглядит как чистокровное зависание: процесс висит в памяти, но сообщения не обрабатываются и в логи ничего не пишется. Из логов удалось сделать только одно наблюдение: что в окрестностях наблюдаемого события вызываемый веб-сервис находился в нестабильном состоянии (майнтенанс у него какой-то был) и активно сыпал ошибками (403 Forbidden).

Оба раза сняли дампы процесса и ничего неожиданного в них не обнаружили. 64 рабочих потока висят на методе .Wait(), 64 HttpWebResponse-a имеют StatusCode=403, и это вовсе не приводит к завершению методов .Wait().

Соорудил тестовый проект, стал пытаться воспроизвести ситуацию. Нашел лишь стабильный способ "искуственно" ввести процесс в аналогичное висячее состояние. Для этого достаточно зациклить один (всего лишь) IO-поток из пула. Например, так:

var client = new WebClient();
client.DownloadStringCompleted += (sender, args) =>
{
   while (true)
   {
      Thread.SpinWait(10000);
   }
};
client.DownloadStringAsync(new Uri("http://bash.im"));


Причем, именно зациклить — Thread.Sleep(-1) недостаточно.
Почему зацикливание одного из IO-потоков приводит к полной остановке всего WCF-а — это само по себе интересно. Но будем пока считать это особенностью реализации WCF.

Экспериментировал с Wcf Facility (думал, может эта штука как-то гадит) — нет, результаты одинаковые и с ним, и без него.
Попробовал вызывать синхронный метод из контракта сервиса. Результат аналогичен: зацикливание IO-потока навсегда вешает и синхронные методы.

Из этого возникло пока умозрительное предположение, что на проде два (или больше) IO-потока входят в некий live lock (неизвестно, какие именно IO-потоки и из-за чего), и тогда все останавливается.

Затем в какой-то момент оно у меня на машине, под отладчиком, вдруг зависло само. И вот, стабильно висит уже пару суток. И выглядит это точь-в-точь, как ранее на проде и при "искуственном вывешивании": обработчики висят на вызове метода веб-сервиса, а какой-то один из потоков целиком занимает одно из четырех ядер процессора (CPU Usage=25% все время).

  Вот состояния всех потоков, если сделать break all
Not Flagged 11496 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 6864 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 7460 0 Worker Thread GC Finalizer Thread Normal
Not Flagged 6764 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 11084 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 13296 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 6832 0 Worker Thread [Thread Destroyed] Normal
Not Flagged 13840 72 Worker Thread Worker Thread Normal
Not Flagged 8860 275 Worker Thread <No Name> Castle.Windsor.dll!Castle.MicroKernel.DefaultKernel.CreateCreationContext Normal
Not Flagged 10456 211 Worker Thread <No Name> Microsoft.VisualStudio.Diagnostics.ServiceModelSink.dll!Microsoft.VisualStudio.Diagnostics.ServiceModelSink.EnabledClientEventSink.AfterReceiveReply Normal
Not Flagged 8956 227 Worker Thread <No Name> Microsoft.VisualStudio.Diagnostics.ServiceModelSink.dll!Microsoft.VisualStudio.Diagnostics.ServiceModelSink.EnabledClientEventSink.AfterReceiveReply Normal
Not Flagged 3428 224 Worker Thread <No Name> Microsoft.VisualStudio.Diagnostics.ServiceModelSink.dll!Microsoft.VisualStudio.Diagnostics.ServiceModelSink.EnabledClientEventSink.AfterReceiveReply Normal
Not Flagged 13812 162 Worker Thread Worker Thread mscorlib.dll!System.Threading.ThreadPool.QueueUserWorkItemHelper Normal
Not Flagged 14448 14 Worker Thread <No Name> NsbService.dll!NsbService.OnStartHandler.Start Normal
Not Flagged 2456 238 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 7796 273 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 1620 259 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 4148 274 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 9456 276 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 14880 277 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 8972 269 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 6980 262 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 12900 271 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 14376 249 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 12860 270 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 13988 261 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 3740 267 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 11632 243 Worker Thread <No Name> NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData Normal
Not Flagged 8304 13 Worker Thread <No Name> NServiceBus.Core.dll!NServiceBus.Timeout.Hosting.Windows.TimeoutPersisterReceiver.Poll Normal
Not Flagged 13164 90 Worker Thread Worker Thread NServiceBus.Core.dll!NServiceBus.Transports.Msmq.MsmqDequeueStrategy.OnPeekCompleted Normal
Not Flagged > 12296 1 Main Thread Main Thread NServiceBus.Host.exe!Topshelf.Internal.Hosts.ConsoleHost.Run Normal
Not Flagged 11884 81 Worker Thread <No Name> System.dll!System.Net.TimerThread.ThreadProc Normal
Not Flagged 2692 272 Worker Thread <No Name> System.dll!System.SecurityUtils.ConstructorInfoInvoke Normal
Not Flagged 9420 245 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.ValueHandle.GetCharText Normal
Not Flagged 6888 246 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 6812 229 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 10396 212 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 9252 173 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 11532 234 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 8652 264 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 12012 248 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 3580 220 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 1684 252 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 2800 236 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 14608 254 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlBufferReader.GetString Normal
Not Flagged 9728 233 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlDictionaryReader.ReadContentAsString Normal
Not Flagged 8492 255 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlDictionaryReader.ReadContentAsString Normal
Not Flagged 5328 235 Worker Thread <No Name> System.Runtime.Serialization.dll!System.Xml.XmlDictionaryReader.ReadContentAsString Normal
Not Flagged 2300 241 Worker Thread <No Name> System.ServiceModel.dll!System.ServiceModel.Channels.BufferedMessage.BufferedMessage Normal
Not Flagged 9648 258 Worker Thread <No Name> System.ServiceModel.dll!System.ServiceModel.Channels.HttpInput.CreateHttpInput Normal
Not Flagged 13824 231 Worker Thread <No Name> System.ServiceModel.dll!System.ServiceModel.Channels.ReceivedFault.CreateFault11 Normal
Not Flagged 2036 210 Worker Thread <No Name> System.ServiceModel.dll!System.ServiceModel.Channels.ReceivedFault.CreateFault11 Normal
Not Flagged 3944 260 Worker Thread <No Name> System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.CreateReturnMessage Normal
Not Flagged 12672 237 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 10200 257 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 2224 265 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 12948 253 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 4560 209 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 9372 244 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 5048 268 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 9284 242 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 11436 250 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 1668 247 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 12204 239 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 11980 240 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.StackTraceString Normal
Not Flagged 12524 223 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.XmlEncode Normal
Not Flagged 10836 251 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.DiagnosticTraceBase.XmlEncode Normal
Not Flagged 13708 266 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString Normal
Not Flagged 3672 221 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.ExceptionTrace.TraceEtwException Normal
Not Flagged 11156 226 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Fx.AllocateByteArray Normal
Not Flagged 13168 228 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Fx.AllocateByteArray Normal
Not Flagged 3536 225 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Fx.AllocateByteArray Normal
Not Flagged 5284 256 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Fx.AllocateByteArray Normal
Not Flagged 6824 263 Worker Thread <No Name> System.Xml.dll!System.Xml.NameTable.Add Normal
Not Flagged 8908 222 Worker Thread <No Name> System.Xml.dll!System.Xml.NameTable.AddEntry Normal
Not Flagged 6792 232 Worker Thread <No Name> System.Xml.dll!System.Xml.NameTable.AddEntry Normal
Not Flagged 15200 230 Worker Thread <No Name> System.Xml.dll!System.Xml.NameTable.Grow Normal
Not Flagged 9008 216 Worker Thread <No Name> System.Xml.dll!System.Xml.NameTable.NameTable Normal

И они не меняются во времени.

Пора бы уже задать вопрос, и давайте начнем с простого (сложные, вида "а не баг ли это в .Net?" будут позже). Смотрю я на этот список потоков в отладчике, туплю и не знаю, как мне теперь понять, какой из них (и где именно) зациклился. Есть ли у кого-нибудь какие-нибудь идеи? Всем спасибо!
Re: WCF, (probably) livelock
От: Sharov Россия  
Дата: 05.03.15 17:31
Оценка:
Здравствуйте, scale_tone, Вы писали:


1)А в wcf'ных логах зависшего сервиса ничего подозрительного нет?
2)Вот нагуглилось, хотя Вы уже, наверное, это видело. Немножко не то, но все же...

_>Почему зацикливание одного из IO-потоков приводит к полной остановке всего WCF-а — это само по себе интересно. Но будем пока считать это особенностью реализации WCF.

Правильно ли я понимаю, что если сделать тестовый метод ping на данном сервисе и момент зависания его вызывать,
то сервис не ответит -- завис, все зависло?


_>[cut=Вот состояния всех потоков, если сделать break all]

Вероятно предлагаю полный идиотизм, но можно с определенной частотой (раз в час) поснимать такие дампы и посмотреть,
кто висит( ну скрипт какой-нибудь написать, и смотреть пересчение threadid дампов).
Кодом людям нужно помогать!
Re[2]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 05.03.15 21:28
Оценка:
Здравствуйте, Sharov, Вы писали:

S>1)А в wcf'ных логах зависшего сервиса ничего подозрительного нет?

WCF-ных лолгов нет Я не догадался включить. Перед следующей попыткой воспроизвести включу обязательно, но щас надо понять, что делать с текущим состоянием (мне надо бы ноут перегрузить, по другим причинам, а я не могу — "любопытный образец" потеряется .


S>2)Вот нагуглилось, хотя Вы уже, наверное, это видело. Немножко не то, но все же...

Не видел, но действительно слегка не то.


_>>Почему зацикливание одного из IO-потоков приводит к полной остановке всего WCF-а — это само по себе интересно. Но будем пока считать это особенностью реализации WCF.

S>Правильно ли я понимаю, что если сделать тестовый метод ping на данном сервисе и момент зависания его вызывать,
S>то сервис не ответит -- завис, все зависло?

Не совсем так. Процесса два.

В одном хостится тестовый веб-сервис с тестовым методом, метод несколько секунд ждет, а затем кидает исключение — я таким образом пытаюсь воспроизвести сценарий на продакшене. С этим процессом все в порядке, он жив и отвечает на запросы (fault-ами).

Второй процесс — это модель рабочего процесса на проде. В нем NServiceBus с 64-мя потоками и обработчик тестового сообщения, дергающий веб-сервис в процессе1. Вот он полностью остановился, все 64 рабочих NSB-потока вечно висят на вызовах метода веб-сервиса, и новых вызовов не выполняется.


_>>[cut=Вот состояния всех потоков, если сделать break all]

S>Вероятно предлагаю полный идиотизм, но можно с определенной частотой (раз в час) поснимать такие дампы и посмотреть,
S>кто висит( ну скрипт какой-нибудь написать, и смотреть пересчение threadid дампов).

Ну вот то-то и оно, что таких дампов я понаделал уже много (путем Debug->Break All) — и они всегда одинаковые. Не меняются во времени. Т.е. как будто все потоки вечно висят. Но на самом деле, висят почти все потоки. А какой-то один из них не висит, а зациклился (судя по CPU Usage). И вот хочется понять, какой.

Пытался фризить потоки (правой кнопкой по потоку->Freeze). Не срабатывает. Почему-то даже если сказать всем потокам Freeze, CPU Usage все равно остается 25%.
Re: WCF, (probably) livelock
От: breee breee  
Дата: 05.03.15 21:56
Оценка: 9 (3)
Здравствуйте, scale_tone, Вы писали:

_>Пора бы уже задать вопрос, и давайте начнем с простого (сложные, вида "а не баг ли это в .Net?" будут позже). Смотрю я на этот список потоков в отладчике, туплю и не знаю, как мне теперь понять, какой из них (и где именно) зациклился. Есть ли у кого-нибудь какие-нибудь идеи? Всем спасибо!

Не знаю поможет ли, но идея такая. Открыть свойства процесса в Process Explorer, вкладка Threads. Там для каждого потока есть User Time. По идее для ждущих потоков оно не меняется, для зациклившегося — увеличивается.
Учитывая, что процесс висит уже несколько суток, можно сразу искать поток с самым большим User Time.

Еще, с той же идеей, можно попробовать приаттачиться к процессу windbg (с галочкой Noninvasiv, т.к. один отладчик уже есть) и выполнить команду !runaway с неким интервалом.
Отредактировано 05.03.2015 22:28 breee breee . Предыдущая версия . Еще …
Отредактировано 05.03.2015 22:14 breee breee . Предыдущая версия .
Re[2]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 06.03.15 09:19
Оценка:
Здравствуйте, breee breee, Вы писали:

BB>Не знаю поможет ли, но идея такая. Открыть свойства процесса в Process Explorer, вкладка Threads. Там для каждого потока есть User Time. По идее для ждущих потоков оно не меняется, для зациклившегося — увеличивается.
BB>Учитывая, что процесс висит уже несколько суток, можно сразу искать поток с самым большим User Time.

Супер! Выяснил Process Explorer-ом ID зациклившегося потока.

  И вот его стек.
Not Flagged 13708 266 Worker Thread <No Name> System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString Normal
[Managed to Native Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString(System.Xml.XmlTextWriter xml = {System.Xml.XmlTextWriter}, System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, int remainingLength = 28649, int remainingAllowedRecursionDepth = 64)
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.ExceptionToTraceString(System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, int maxTraceStringLength = 28672)
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.GetSerializedPayload(object source = null, System.Runtime.Diagnostics.TraceRecord traceRecord = null, System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, bool getServiceReference = false)
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.GetSerializedPayload(object source = null, System.Runtime.Diagnostics.TraceRecord traceRecord = null, System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."})
System.ServiceModel.Internals.dll!System.Runtime.TraceCore.ThrowingEtwException(System.Runtime.Diagnostics.EtwDiagnosticTrace trace = {System.Runtime.Diagnostics.EtwDiagnosticTrace}, string param0 = "System.ServiceModel 4.0.0.0", string param1 = "System.ServiceModel.FaultException: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.", System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."})
System.ServiceModel.Internals.dll!System.Runtime.ExceptionTrace.TraceEtwException(System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, System.Diagnostics.TraceEventType eventType = Warning)
SMDiagnostics.dll!System.ServiceModel.Diagnostics.ExceptionUtility.ThrowHelper(System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, System.Diagnostics.TraceEventType eventType = Warning, System.Runtime.Diagnostics.TraceRecord extendedData = null)
SMDiagnostics.dll!System.ServiceModel.Diagnostics.ExceptionUtility.ThrowHelper(System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."}, System.Diagnostics.TraceEventType eventType = Warning)
SMDiagnostics.dll!System.ServiceModel.Diagnostics.ExceptionUtility.ThrowHelperWarning(System.Exception exception = {"The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs."})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(System.ServiceModel.Channels.Message reply = {System.ServiceModel.Channels.BufferedMessage}, System.ServiceModel.Channels.MessageFault fault = {System.ServiceModel.Channels.ReceivedFault}, string action = null, System.ServiceModel.Channels.MessageVersion version = {System.ServiceModel.Channels.MessageVersion}, System.ServiceModel.Channels.FaultConverter faultConverter = {System.ServiceModel.Channels.FaultConverter.DefaultFaultConverter})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.HandleReply(System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime}, ref System.ServiceModel.Dispatcher.ProxyRpc rpc = {System.ServiceModel.Dispatcher.ProxyRpc})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.Call(string action = "http://tempuri.org/ITestService/GetData", bool oneway = false, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime}, object[] ins = {object[1]}, object[] outs = {object[0]}, System.TimeSpan timeout = {System.TimeSpan})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannel.Call(string action = "http://tempuri.org/ITestService/GetData", bool oneway = false, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime}, object[] ins = {object[1]}, object[] outs = {object[0]})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(System.Runtime.Remoting.Messaging.IMethodCallMessage methodCall = {System.Runtime.Remoting.Messaging.Message}, System.ServiceModel.Dispatcher.ProxyOperationRuntime operation = {System.ServiceModel.Dispatcher.ProxyOperationRuntime})
System.ServiceModel.dll!System.ServiceModel.Channels.ServiceChannelProxy.Invoke(System.Runtime.Remoting.Messaging.IMessage message = {System.Runtime.Remoting.Messaging.Message})
mscorlib.dll!System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(ref System.Runtime.Remoting.Proxies.MessageData msgData, int type)
NsbService.dll!NsbService.TestServiceReference.TestServiceClient.GetData(int value = 123) Line 122
NsbService.dll!NsbService.TestMessageHandler.Handle(NsbMessages.TestMessage message = {NsbMessages.TestMessage}) Line 40
[Lightweight Function]
NServiceBus.Core.dll!NServiceBus.Unicast.HandlerInvocationCache.Invoke(object handler = {NsbService.TestMessageHandler}, object message = {NsbMessages.TestMessage}, System.Collections.Generic.Dictionary<System.RuntimeTypeHandle,System.Collections.Generic.List<NServiceBus.Unicast.HandlerInvocationCache.DelegateHolder>> dictionary = Count = 2) Line 61
NServiceBus.Core.dll!NServiceBus.Unicast.HandlerInvocationCache.InvokeHandle(object handler = {NsbService.TestMessageHandler}, object message = {NsbMessages.TestMessage}) Line 22
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.LoadHandlersBehavior.Invoke.AnonymousMethod__1(object handlerInstance = {NsbService.TestMessageHandler}, object message = {NsbMessages.TestMessage}) Line 42
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.InvokeHandlersBehavior.DispatchMessageToHandlersBasedOnType(NServiceBus.ObjectBuilder.IBuilder builder = {NServiceBus.ObjectBuilder.Common.CommonObjectBuilder}, NServiceBus.Unicast.Messages.LogicalMessage toHandle = {NServiceBus.Unicast.Messages.LogicalMessage}, NServiceBus.Unicast.Behaviors.MessageHandler messageHandler = {NServiceBus.Unicast.Behaviors.MessageHandler}) Line 61
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.InvokeHandlersBehavior.Invoke(NServiceBus.Pipeline.Contexts.HandlerInvocationContext context = {NServiceBus.Pipeline.Contexts.HandlerInvocationContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 27
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Sagas.SagaPersistenceBehavior.Invoke(NServiceBus.Pipeline.Contexts.HandlerInvocationContext context = {NServiceBus.Pipeline.Contexts.HandlerInvocationContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 32
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Sagas.AuditInvokedSagaBehavior.Invoke(NServiceBus.Pipeline.Contexts.HandlerInvocationContext context = {NServiceBus.Pipeline.Contexts.HandlerInvocationContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 18
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.SetCurrentMessageBeingHandledBehavior.Invoke(NServiceBus.Pipeline.Contexts.HandlerInvocationContext context = {NServiceBus.Pipeline.Contexts.HandlerInvocationContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 21
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Pipeline.PipelineExecutor.Execute<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>(NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext> pipelineAction = {NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.HandlerInvocationContext>}, NServiceBus.Pipeline.Contexts.HandlerInvocationContext context = {NServiceBus.Pipeline.Contexts.HandlerInvocationContext}) Line 138
NServiceBus.Core.dll!NServiceBus.Pipeline.PipelineExecutor.InvokeHandlerPipeline(NServiceBus.Unicast.Behaviors.MessageHandler handler = {NServiceBus.Unicast.Behaviors.MessageHandler}) Line 67
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.LoadHandlersBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 45
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.DataBus.DataBusReceiveBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 69
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Pipeline.MessageMutator.ApplyIncomingMessageMutatorsBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 26
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Pipeline.PipelineExecutor.Execute<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext>(NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext> pipelineAction = {NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext>}, NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceiveLogicalMessageContext}) Line 138
NServiceBus.Core.dll!NServiceBus.Pipeline.PipelineExecutor.InvokeLogicalMessagePipeline(NServiceBus.Unicast.Messages.LogicalMessage message = {NServiceBus.Unicast.Messages.LogicalMessage}) Line 58
NServiceBus.Core.dll!NServiceBus.Unicast.Messages.ExecuteLogicalMessagesBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 28
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.CallbackInvocationBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 27
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Messages.ExtractLogicalMessagesBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 59
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Sagas.RemoveIncomingHeadersBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 24
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.RaiseMessageReceivedBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 19
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.MessageMutator.ApplyIncomingTransportMessageMutatorsBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 23
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.UnitOfWork.UnitOfWorkBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 25
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.ForwardBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 26
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Audit.AuditBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 18
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.ImpersonateSenderBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 37
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.MessageHandlingLoggingBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 23
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Unicast.Behaviors.ChildContainerBehavior.Invoke(NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext context = {NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext}, System.Action next = {Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.}) Line 17
NServiceBus.Core.dll!NServiceBus.Pipeline.BehaviorChain<NServiceBus.Pipeline.Contexts.ReceivePhysicalMessageContext>.Invoke() Line 36
NServiceBus.Core.dll!NServiceBus.Pipeline.PipelineExecutor.InvokeReceivePhysicalMessagePipeline() Line 45
NServiceBus.Core.dll!NServiceBus.Unicast.UnicastBus.TransportMessageReceived(object sender = {NServiceBus.Unicast.Transport.TransportReceiver}, NServiceBus.Unicast.Transport.TransportMessageReceivedEventArgs e = {NServiceBus.Unicast.Transport.TransportMessageReceivedEventArgs}) Line 1100
NServiceBus.Core.dll!NServiceBus.Unicast.Transport.TransportReceiver.OnTransportMessageReceived(NServiceBus.TransportMessage msg = {NServiceBus.TransportMessage}) Line 441
NServiceBus.Core.dll!NServiceBus.Unicast.Transport.TransportReceiver.ProcessMessage(NServiceBus.TransportMessage message = {NServiceBus.TransportMessage}) Line 356
NServiceBus.Core.dll!NServiceBus.Unicast.Transport.TransportReceiver.TryProcess(NServiceBus.TransportMessage message = {NServiceBus.TransportMessage}) Line 259
NServiceBus.Core.dll!NServiceBus.Transports.Msmq.MsmqDequeueStrategy.Action() Line 261
mscorlib.dll!System.Threading.Tasks.Task.Execute()
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)
mscorlib.dll!System.Threading.Tasks.Task.ExecuteWithThreadLocal(ref System.Threading.Tasks.Task currentTaskSlot = Id = 2, Status = Running, Method = Inspecting the state of an object in the debuggee of type System.Delegate is not supported in this context.)
mscorlib.dll!System.Threading.Tasks.Task.ExecuteEntry(bool bPreventDoubleExecution)
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx)
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state)
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart(object obj)
[Native to Managed Transition]


Пойдем копать дальше...
Re[3]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 06.03.15 21:54
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>Пойдем копать дальше...

С помощью того же Process Explorer-a поснимал несколько стеков этого зациклившегося потока. Вот они:

  раз
ntdll.dll!ZwSetEvent+0xa
KERNELBASE.dll!SetEvent+0xc
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x730dc
clr.dll!StrongNameTokenFromAssemblyEx+0x1152f5
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  два
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x7309a
clr.dll!StrongNameTokenFromAssemblyEx+0x1152f5
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  три
clr.dll!LogHelp_LogAssert+0x3a13
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x73092
clr.dll!StrongNameTokenFromAssemblyEx+0x1152f5
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  четыре
ntdll.dll!ZwSetEvent+0xa
KERNELBASE.dll!SetEvent+0xc
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x730dc
clr.dll!StrongNameTokenFromAssemblyEx+0x1152f5
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  пять
clr.dll!LogHelp_LogAssert+0x3a13
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x5ff76
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70e26
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  шесть
clr.dll!LogHelp_LogAssert+0x39f3
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x5ff76
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70e26
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


  семь
clr.dll!LogHelp_LogAssert+0x363c
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70df0
clr.dll!GetMetaDataInternalInterfaceFromPublic+0x70613
clr.dll!LogHelp_LogAssert+0x2da8
[Managed to Unmanaged Transition]
System.ServiceModel.Internals.dll!System.Runtime.Diagnostics.EtwDiagnosticTrace.WriteExceptionToTraceString+0x26a
<и т.д.>


В общем, видно, что трабла какая-то глубоко системная. И че делать, пока непонятно...
Re[4]: WCF, (probably) livelock
От: Codechanger Россия  
Дата: 06.03.15 22:09
Оценка:
Здравствуйте, scale_tone, Вы писали:
_>В общем, видно, что трабла какая-то глубоко системная. И че делать, пока непонятно...

Попробуйте в журнале msmq глянуть, что там с сообщениями.Возможно, там какое-нить залипло.
Re[5]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 07.03.15 09:22
Оценка:
Здравствуйте, Codechanger, Вы писали:

C>Попробуйте в журнале msmq глянуть, что там с сообщениями.Возможно, там какое-нить залипло.

Они там все залипли. Они не обрабатываются, я это точно знаю.
Re: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 14.03.15 18:34
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>Затем в какой-то момент оно у меня на машине, под отладчиком, вдруг зависло само. И вот, стабильно висит уже пару суток. И выглядит это точь-в-точь, как ранее на проде и при "искуственном вывешивании": обработчики висят на вызове метода веб-сервиса, а какой-то один из потоков целиком занимает одно из четырех ядер процессора (CPU Usage=25% все время).

Ну в общем, природа явления осталась туманной. Тест пришлось убить.
Ждем нового зависания на проде. Будем смотреть стеки потоков там.

Meanwhile, никто случайно не знает, что бы сделать такого, чтоб оно больше не висло?
Или может, кто-нибудь готов порассуждать на тему остановки всего WCF при зацикливании IO-потока (почему оно так? нельзя ли сделать, чтоб так не было)?
Буду глубоко благодарен!
Re[2]: WCF, (probably) livelock
От: Sharov Россия  
Дата: 15.03.15 18:29
Оценка: +1
Здравствуйте, scale_tone, Вы писали:

_>Meanwhile, никто случайно не знает, что бы сделать такого, чтоб оно больше не висло?
_>Или может, кто-нибудь готов порассуждать на тему остановки всего WCF при зацикливании IO-потока (почему оно так? нельзя ли сделать, чтоб так не было)?
_>Буду глубоко благодарен!

Я бы пока обратился к более масштабной англоязычной публике на SO или/и msdn. Мож кто-нибудь с чем-нибудь подобным сталкивался,
или расскажут, что это известная, но не всем, бага WCF.
Кодом людям нужно помогать!
Re[2]: WCF, (probably) livelock
От: drol  
Дата: 16.03.15 18:22
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>Или может, кто-нибудь готов порассуждать на тему остановки всего WCF при зацикливании IO-потока (почему оно так? нельзя ли сделать, чтоб так не было)?

Насколько я помню Ваши stacktrace'ы там заклинило ETW-логирование. Остальные потоки видать ждут в своих вызовах лог-методов пока оно закончит...
Re[3]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 16.03.15 20:17
Оценка:
Здравствуйте, drol, Вы писали:

D>Насколько я помню Ваши stacktrace'ы там заклинило ETW-логирование.

Пожалуй, да, в последнем инциденте на моей машине заклинило где-то там...

D> Остальные потоки видать ждут в своих вызовах лог-методов пока оно закончит...

Скорее, они ждут чего-то другого. Ибо они останавливаются с теми же симптомами и стеками, если принудительно подвесить IO-поток
Re: WCF, (probably) livelock
От: Lexey Россия  
Дата: 18.03.15 15:57
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>Уже дважды на продакшене наблюдали полное зависание одного нашего сервиса. Сервис обрабатывает входящие сообщения (используем NServiceBus c MSMQ-транспортом, все на .Net 4.5).

Пару лет назад использовали NServiceBus + MSMQ в качестве шины для приложения для промышленной автоматизации. Обплевались с него из-за эпизодически вылезающих глюков в кишках NServiceBus (сообщения просто переставали приниматься).
В итоге переехали на Masstransit. Глюки исчезли.
"Будь достоин победы" (c) 8th Wizard's rule.
Re[2]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 18.03.15 17:57
Оценка:
Здравствуйте, Lexey, Вы писали:

L>Пару лет назад использовали NServiceBus + MSMQ в качестве шины для приложения для промышленной автоматизации.

Ого! SCADA на NSB+MSMQ?! Как-то это ээ... необычно

L>Обплевались с него из-за эпизодически вылезающих глюков в кишках NServiceBus (сообщения просто переставали приниматься).

Ну, я тоже не могу назвать NSB беспроблемным фреймворком. Но гейзенбагов мы в нем пока не замечали.
И в рассматриваемом нами сценарии он наверняка не причем.
Re[2]: WCF, (probably) livelock
От: johny5 Новая Зеландия
Дата: 24.03.15 23:58
Оценка:
Здравствуйте, scale_tone, Вы писали:

_>Meanwhile, никто случайно не знает, что бы сделать такого, чтоб оно больше не висло?

Возможно сделать Wait с таймаутом?
Re[3]: WCF, (probably) livelock
От: scale_tone Норвегия https://scale-tone.github.io/
Дата: 25.03.15 06:38
Оценка:
Здравствуйте, johny5, Вы писали:

J>Возможно сделать Wait с таймаутом?

Не помогает: после зависания даже Wait-ы с таймаутом не завершаются.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.