2017-12-24 1 views
2

Ich finde eine Menge OperationCanceledException s in meinem API-Protokoll. I denke es ist mit hohen Lastbedingungen verbunden, aber das könnte nur daran liegen, dass unter höherer Last eine höhere Anzahl von Anrufen und daher eine höhere Anzahl von Ausnahmen. Der Stack-Trace der Ausnahme erreicht keinen Controller-Code; Es passiert einige meiner OWIN-Middleware, stirbt aber, bevor es einen Controller erreicht. Und es ist die gleiche Stack-Trace für viele Anrufe an verschiedenen API-Endpunkten:Was verursacht OperationCanceledException in der OWIN-Pipeline?

System.OperationCanceledException: The operation was canceled. 
    at System.Threading.CancellationToken.ThrowOperationCanceledException() 
    at System.Net.Http.HttpContentExtensions.<ReadAsAsyncCore>d__0`1.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.ModelBinding.FormatterParameterBinding.<ExecuteBindingAsyncCore>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Web.Http.Controllers.HttpActionBinding.<ExecuteBindingAsyncCore>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.Controllers.ActionFilterResult.<ExecuteAsync>d__2.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.Filters.AuthorizationFilterAttribute.<ExecuteAuthorizationFilterAsyncCore>d__2.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.Dispatcher.HttpControllerDispatcher.<SendAsync>d__1.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at MyDomain.Api.Handlers.ApiCultureHandler.<SendAsync>d__0.MoveNext() in D:\Bamboo\xml-data\build-dir\API-R5V3-JOB1\src\Api\Handlers\ApiCultureHandler.cs:line 50 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.HttpServer.<SendAsync>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at System.Web.Http.Owin.HttpMessageHandlerAdapter.<InvokeCore>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.Owin.Cors.CorsMiddleware.<Invoke>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContextStage.<RunApp>d__5.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1.<Invoke>d__0.MoveNext() 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at DependencyResolution.Api.Middleware.AuditLogMiddleware.<Invoke>d__1.MoveNext() in D:\Bamboo\xml-data\build-dir\API-R5V3-JOB1\src\DependencyResolution\Api\Middleware\AuditLogMiddleware.cs:line 23 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at DependencyResolution.Api.Middleware.ShardingMiddleware.<Invoke>d__2.MoveNext() in D:\Bamboo\xml-data\build-dir\API-R5V3-JOB1\src\DependencyResolution\Api\Middleware\ShardingMiddleware.cs:line 77 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at DependencyResolution.Api.Middleware.StructureMapMiddleware.<Invoke>d__2.MoveNext() in D:\Bamboo\xml-data\build-dir\API-R5V3-JOB1\src\DependencyResolution\Api\Middleware\StructureMapMiddleware.cs:line 29 
--- End of stack trace from previous location where exception was thrown --- 
    at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() 
    at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) 
    at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) 
    at DependencyResolution.Api.Middleware.ExceptionHandlerMiddleware.<Invoke>d__3.MoveNext() in D:\Bamboo\xml-data\build-dir\API-R5V3-JOB1\src\DependencyResolution\Api\Middleware\ExceptionHandlerMiddleware.cs:line 33 

Diese sehr störend ist, wie ich bin nicht sicher, wie dies zu debuggen.

Weitere möglicherweise nützliche Informationen: Zum Zeitpunkt, als diese Fehler auftraten, zeigte einer meiner API-Server, was ich das "Bart Simpson" -Muster in der CPU-Nutzung nennen. Die CPU würde 20-30 Sekunden lang in den Bereich von 95-100% schießen, dann würde sie für weitere 20-30 Sekunden auf 5-10% fallen und dann wieder hochfahren. Der Zyklus wiederholte sich auf unbestimmte Zeit. Da wir in Produktion waren, hatte ich keine Zeit, viel weiter zu forschen. Ich habe diesen Server getötet und ließ unsere Autoscaling-Regeln einen neuen Server aufstellen, der dann gut funktionierte. Aber ich habe keine Garantie, dass das Bart Simpson-Muster andere API-Server, die wir aufrufen, nicht beeinflusst, und ich habe keine Ahnung, was das verursachen könnte.

Irgendwelche Ideen?

+0

Von den mittleren Waren in der Stack-Trace, die benutzerdefinierte und welche sind 3rd Party? Alles, was nicht von Ihnen oder Ihrem Team geschrieben wurde, ist ein Drittanbieter. – Nkosi

+0

@Nkosi Alles, was mit 'DependencyResolution' oder' MyDomain' (offensichtlich sterilisiert) beginnt, wird im Haus geschrieben. Der Rest ist Microsoft. –

+0

Es ist möglich, dass Sie irgendwo in einem dieser Inhouse-Module asynchrone Warte- und Blockierungsaufrufe ('.Result' oder' .Wait() ') mischen, die zu einem Deadlock führen können, der dazu führt, dass der Vorgang abläuft und abgebrochen wird. Der Stack-Trace hat Ihnen bereits eine Liste von Verdächtigen zur Verfügung gestellt. – Nkosi

Antwort

1

Da in Ihrem Code im Call-Stack kein anderer Fehler auftritt, ist dies wahrscheinlich ein falscher Alarm. Wenn der Client die Verbindung beendet, bevor der Server antwortet, wird der Vorgang abgebrochen. Angenommen, Ihr Client hat einen Heartbeat-Endpunkt, den er alle 5 Sekunden aufruft, und der Anruf dauert 250 ms. Jedes Mal, wenn ein Client herunterfährt, besteht eine Wahrscheinlichkeit von 5%, dass ein Vorgang abgebrochen wird. Es gibt viele normale Szenarien, in denen eine Verbindung vom Client abgeschnitten werden kann, bevor eine Antwort empfangen wird. OperationCanceledException selbst sollte kein Grund zur Besorgnis sein. Berücksichtigen Sie jedoch die Häufigkeit in Bezug auf die Anzahl der Kunden und Ihre spezifische Anwendung.

1

Wie besprochen, es möglich ist, dass irgendwo in einem dieser benutzerdefinierten Middleware in der Stapelüberwachung aufgeführt, kann es zu einer Vermischung von async sein erwartet und blockierende Aufrufe (.Result oder .Wait()), die es zu führen, kann ein Deadlock, der den Vorgang verursacht, hängen, Timeout und Abbrechen.

Das Stack-Trace-Snippet enthält bereits eine Liste mit möglichen Verdächtigen.

Es wird empfohlen, mit der Überprüfung der Invoke der aufgeführten Middleware, die die Anforderungs-Pipeline behandeln.

+0

Es war eine großartige Idee, und ich habe in einem umfangreichen Refactoring alle möglichen Blockierungscodes ausgerottet, aber leider bekommen wir immer noch den Fehler ... –

Verwandte Themen