3

I'm using the latest SignalR from NuGet in a MVC4 site. Using the sample hub code (or any code), I'm getting some weird connection problems. Everything loads fine, SignalR makes the negotiate call and logs "EventSource Connected" and returns connectionid. The problem starts when it makes the signalR/connect request with any transport. It returns a 200 response with the proper headers but the connection hangs open. If the called hub method executes a method on Caller or Clients, it does not get executed in the browser until the next request OR after 10-30 seconds later if you sit and wait. It's like something's stuck in the pipe and it gets flushed by the next request or some cleanup mechanism.

I made a clean project for this in a new website with its own app pool. The issue occurs only on one machine and only under IIS7.5. The same project run on the same machine under IIS Express or Cassini works fine. This project ran fine the last time I worked on it about a month ago. I've tried different browsers and different jQuery versions. I've tried restarting the entire machine and spent several hours in fiddler/debugger to no avail.

This is the server-side code the test runs:

public class Chub : Hub {
    public void CallMeBack() {
        Caller.callme();
    }
}

Blew the whole day on this, hope someone can help!

Kara
  • 6,115
  • 16
  • 50
  • 57
kenchilada
  • 7,469
  • 5
  • 25
  • 34
  • 1
    Do you have compression turned on for application/json? Check if any of the responses has Content-Encoding: gzip header in Fiddler. – Alexander Köplinger Oct 16 '12 at 17:37
  • 1
    Yep, that was it. It's rather humiliating to be stuck this long on something and the resolution is unticking one checkbox. If you want to post this as the answer I'll come back and accept it. – kenchilada Oct 17 '12 at 01:24

1 Answers1

4

Compression doesn't play well with streaming responses like EventSource, ForeverFrame, etc. as used by SignalR, so switching off compression is the only solution right now.

Maybe it's possible to switch off compression just for the ~/signalr path, I'll try that later on and update this answer with the results.

UPDATE: After a thorough analysis, I've found out this issue only occurs when the application pool is set to "Classic Mode" in IIS and Dynamic Compression is enabled. See my comment on this SignalR issue. If you use an "Integrated Mode" application pool, you are not affected and SignalR works as expected (even if compression is enabled).

In case you're stuck with Classic Mode + Dynamic Compression, add the following to your web.config for switching off compression only for the /signalr path:

<location path="signalr">
  <system.webServer>
    <urlCompression doDynamicCompression="false"/>
  </system.webServer>
</location>
Alexander Köplinger
  • 2,497
  • 17
  • 15
  • Plus 1. Btw that dropbox is empty now. Can you please upload it? –  Oct 16 '13 at 05:32
  • I could, but why do you need it (the repro is just a very basic chat-style app)? There's nothing that can be done when you run in IIS Classic mode + dynamic compression turned on. – Alexander Köplinger Oct 16 '13 at 12:02