Debugging SignalR hang

Windows 7, SignalR2.

I have some HelloWorld SignalR code that works in one VS2013 project (Ie, my SignalR hello world playground).

When I add the same code to an existing application, SignalR threads "hang" in IIS "forever". This happens every single time.

My SignalR console looks like:

My perfMon counters look like this:

My worker process list looks like:

I'm after some tips on where to start debugging. In Java, I would take a thread dump and I could see what is going on fairly easily.

These threads are not visible in VS2013 when attached as a debugger.

There does not seem to be an equivalent in IIS/DotNet?

Here is my 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;
        }
    }

Here is my client, truncated to the simplest hanging scenario.

$(function () {


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

There is lots of about SignalR hangs in IIS with SignalR 1, but I'm using SignalR 2.

Can someone please tell me how to start debugging what is going on. This tool looks interesting, but I have no idea what it is https://github.com/SignalR/SignalR/issues/1335 (https://github.com/SignalR/SignalR/issues/1335)

Here is the Managed call stack of one of the stuck threads

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]]

回答1:

Do you happen to have an Application_PreSendRequestHeaders method defined or are you in some other way attached to the HttpApplication.PreSendRequestHeaders event?

I ask, because this seems to be the same issue reported here. For at least some people on that thread, removing the PreSendRequestHeaders event handler resolved the issue.

While we recommend you never use the PreSendRequestHeaders event, we are actively working on this issue so we can get a fix out for 2.1.1.

If you are not attaching to the PreSendRequestHeaders event, we (the SignalR team) could use your help. So far, we have not been able to reproduce this issue without attaching to the PreSendRequestHeaders event. If you could provide us with an application that doesn't attach to this event, yet still hangs in this manner, we would greatly appreciate it.

The previous version of SignalR (2.0.3), did not make requests to /signalr/start and does not experience this hang. So you can temporarily work around this issue by downgrading from SignalR 2.1.0 to 2.0.3 until 2.1.1 is released.

回答2:

We traced this problem back to Glimpse.ASPNet. It attaches itself to PreSendRequestHeaders. Therefore, if you use Glimpse.ASPNet with SignalR, you might find you get threads locking up "forever".

Removing Glimpse.AspNet fixes the problem