Calling client from Hub hangs on Azure #510

Closed
mfanto opened this Issue Jul 4, 2012 · 16 comments

Projects

None yet

6 participants

@mfanto
mfanto commented Jul 4, 2012

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
Member

Are you using azure websites?

@mfanto
mfanto commented Jul 4, 2012

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

@davidfowl
Member

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
mfanto commented Jul 4, 2012

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
jsassner commented Jul 6, 2012

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
Member

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

@davidfowl davidfowl closed this Jul 8, 2012
@nberardi
Contributor

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
Member

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

@devpascoe

any update on this?

@chevex
chevex commented Oct 3, 2012

I too am having this issue. Any update?

@davidfowl
Member

There's no update. Use longpolling for now.

@chevex
chevex commented Oct 3, 2012

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

@davidfowl
Member

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

@davidfowl
Member

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

@chevex
chevex commented Nov 2, 2012

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

@davidfowl
Member

Nope

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment