Mise au point du signalR hang

Question

Windows 7, SignalR2.

J'ai un code HelloWorld SignalR qui fonctionne dans un projet VS2013 (par exemple, mon terrain de jeu SignalR hello world).

Lorsque j'ajoute le même code à une application existante, les threads SignalR "se bloquent" dans IIS "pour toujours". Cela arrive à chaque fois.

Ma console SignalR ressemble:

Mes compteurs perfmon ressembler à ceci:

Ma liste de processus de travail ressemble à:

Je suis après quelques conseils sur où commencer le débogage. En Java, je prenais un vidage de fil et je pouvais voir ce qui se passait assez facilement.

Ces threads ne sont pas visibles dans VS2013 lorsqu'ils sont connectés en tant que débogueur.

Il ne semble pas y avoir d'équivalent dans IIS/DotNet?

Voici mon hub:

public class Ep1DataImportHub : Hub 
{ 
    public int recordsToBeProcessed = 100000; 

     public void DoLongOperation() 
     { 
      for (int record = 0; record <= recordsToBeProcessed; record++) 
      { 
       if (ShouldNotifyClient(record)) 
       { 
        Clients.Caller.sendMessage(string.Format 
        ("Processing item {0} of {1}", record, recordsToBeProcessed)); 
        Thread.Sleep(10); 
       } 
      } 
     } 

     private static bool ShouldNotifyClient(int record) 
     { 
      return record % 10 == 0; 
     } 
    } 

Voici mon client, tronquée au scénario de suspension simple.

$(function() { 


    // Initialize the connection to the server 
    var realtimeNotifier = $.connection.ep1DataImportHub; 
    $.connection.hub.logging = true; 
    $.connection.hub.start(); 
}) 

Il y a beaucoup d'environ SignalR se bloque dans IIS avec SignalR 1, mais je suis en utilisant SignalR 2.

Quelqu'un peut-il s'il vous plaît me dire comment démarrer le débogage ce qui se passe. Cet outil semble intéressant, mais je ne sais pas ce qu'il est https://github.com/SignalR/SignalR/issues/1335 (https://github.com/SignalR/SignalR/issues/1335)

Voici la pile d'appel géré d'un des fils coincés

System_Web_ni!DomainNeutralILStubClass.IL_STUB_PInvoke(IntPtr, Boolean, Boolean ByRef)+8f 
[[InlinedCallFrame] (System.Web.Hosting.UnsafeIISMethods.MgdExplicitFlush)] System.Web.Hosting.UnsafeIISMethods.MgdExplicitFlush(IntPtr, Boolean, BooleanByRef) 
System_Web_ni!System.Web.Hosting.IIS7WorkerRequest.ExplicitFlush()+20 
System_Web_ni!System.Web.HttpResponse.Flush(Boolean, Boolean)+c3 
System_Web_ni!System.Web.HttpWriter.WriteFromStream(Byte[], Int32, Int32)+a0 
Microsoft.Owin.Host.SystemWeb.CallStreams.DelegatingStream.Write(Byte[], Int32, Int32)+3a 
Microsoft.Owin.Host.SystemWeb.CallStreams.OutputStream.Write(Byte[], Int32, Int32)+3b 
Microsoft.AspNet.SignalR.Owin.ServerResponse.Write(System.ArraySegment`1)+24 
Microsoft.AspNet.SignalR.Hosting.ResponseExtensions.End(Microsoft.AspNet.SignalR.Hosting.IResponse, System.String)+c8 
Microsoft.AspNet.SignalR.PersistentConnection+d__f.MoveNext()+180 
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+285 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+9 
mscorlib_ni!System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run()+a4 
System_Web_ni!System.Web.Util.SynchronizationHelper.SafeWrapCallback(System.Action)+b4 
mscorlib_ni!System.Threading.Tasks.Task.Execute()+6e 
mscorlib_ni!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+285 
mscorlib_ni!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)+9 
mscorlib_ni!System.Threading.Tasks.Task.ExecuteWithThreadLocal(System.Threading.Tasks.Task ByRef)+250 
mscorlib_ni!System.Threading.Tasks.Task.ExecuteEntry(Boolean)+85 
mscorlib_ni!System.Threading.ThreadPoolWorkQueue.Dispatch()+1ea 
[[DebuggerU2MCatchHandlerFrame]] 
[[ContextTransitionFrame]] 
[[DebuggerU2MCatchHandlerFrame]] 

Answer 1

Auriez-vous d'avoir une méthode Application_PreSendRequestHeaders définie ou êtes-vous lié d'une autre manière à l'événement HttpApplication.PreSendRequestHeaders?

Je demande, parce que cela semble être le même problème signalé here. Pour au moins certaines personnes de ce thread, la suppression du gestionnaire d'événements PreSendRequestHeaders a résolu le problème.

Alors que nous recommend you never use the PreSendRequestHeaders event, nous sommes activement working on this issue afin que nous puissions obtenir une solution pour 2.1.1.

---

Si vous n'êtes pas attachés à l'événement PreSendRequestHeaders, nous (l'équipe SignalR) pourrait utiliser votre aide. Jusqu'à présent, nous n'avons pas été en mesure de reproduire ce problème sans nous attacher à l'événement PreSendRequestHeaders. Si vous pouviez nous fournir une application qui ne se rattache pas à cet événement, mais qui pend toujours de cette manière, nous l'apprécierions grandement.

La version précédente de SignalR (2.0.3), n'a pas fait de demandes à/signalr/start et ne rencontre pas ce blocage. Donc vous pouvez temporairement contourner ce problème en déclassant de SignalR 2.1.0 à 2.0.3 jusqu'à ce que 2.1.1 soit publié.

Answer 2

Nous avons retracé ce problème à Glimpse.ASPNet. Il s'attache à PreSendRequestHeaders. Par conséquent, si vous utilisez Glimpse.ASPNet avec SignalR, vous risquez de voir des threads se verrouiller "pour toujours".

Suppression Glimpse.AspNet résout le problème