Calling client from Hub hangs on Azure

[mfanto]

I'm seeing some very strange behavior with SignalR running on an Azure website with ASP.NET MVC 4 and SignalR 0.5.2. Locally, running under Windows 7 with IIS and VS 2012, everything works properly with no latency issues. Under Azure, Caller.someMethod() can take up to 20 seconds to run.

Here's the general pattern:

I have a bunch of messages displayed on the site. When the user clicks delete, it calls my SignalR hub to delete a message:
hub.deleteMessage(id);

Server side, the hub makes a couple Entity Framework queries, and then calls Clients[group].removeMessage(id);

All this works fine locally. On Azure however, it takes up to 20 seconds for the caller to have removeMessage() invoked. I've modified the code so instead of calling every client, I just call the caller: Caller.removeMessage(id);

This can also take up to 20 seconds to invoke. To try and get a better understanding of what was causing the latency, I started placing StopWatches around the code, resulting in:

          Stopwatch st = new Stopwatch();

           _database.DeleteMessage(id);

            st.Start();
            //Clients[groupname].removeMessage(id);
            Caller.removeMessage(id);

            st.Stop();

           Caller.timing(st.ElapsedTicks);

Note: Caller.timing() is a client side method that shows an alert() with the elapsed time.

Now, the first call to Caller.removeMessage() happens instantly, and the call to Caller.timing() takes up to 20 seconds to invoke.

I hope this description makes sense. I'm using SignalR quite heavily and it works wonderfully locally. It's just this minor issue I'm seeing on Azure.

[davidfowl]

Are you using azure websites?

[mfanto]

Yes, the new Azure websites, with Azure SQL as the store.

[davidfowl]

See #330. Azure websites is buffering data from SSE requests. You can use longPolling as a workaround. I'm working with the team to solve this issue.

[mfanto]

Looks like that's it. Changing to longPolling fixed it. Please let me know if you need me to test anything with any potential fixes. SignalR has been awesome so far and is by far one of the coolest libraries I've used. Thank you for your efforts.

[jsassner]

I have the same issue for some, not all, of my clients. What happens for them is that they send a message to the server (which gets there instantly), but the response takes 10-12 seconds to return. The client tried IE, FF, Chrome and Opera, same thing. The customer had partly success when using an android browser - touching the screen in some other spot after sending the message made the return call from the server arrive.
So it seemed to be some kind of buffering going on somewhere.

We also tried turning off client antivirus, but no change.

What i did to solve that problem was to add a dummy call right after sending the message to clients. But that's just annoying.

Clients[groupName].addMessage(...);
Clients[groupName].refresh();

Using version 0.5.2, hosted on 2008r2 iis 7.5 in classic mode. Not Azure hosted as posts before in this thread.

[davidfowl]

If you can't figure out what's causing the buffering you can always use longPolling.

[nberardi]

Same issue with persistent connections. I have noticed that there is about a 15 second delay on the response, anybody else have any metrics on this?

[davidfowl]

@nberardi Hubs are built on PersistentConnections the bug is the buffering in windows azure websites.

[devpascoe]

any update on this?

[catdadcode]

I too am having this issue. Any update?

[davidfowl]

There's no update. Use longpolling for now.

[catdadcode]

Let's just skip server-sent events, upgrade to .NET 4.5 on azure websites, and jump right into websockets ;)

[davidfowl]

Once it supports windows server 2012 and all of the relevant pieces support websockets (like ARR) then sure it'll "just work".

[davidfowl]

The bug is fixed but won't be deployed to azure for a month or so.

[catdadcode]

Does this bug occur with websockets now that azure supports them?

[davidfowl]

Nope