New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Calling client from Hub hangs on Azure #510

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

Comments

Projects
None yet
6 participants
@mfanto
Copy link

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

This comment has been minimized.

Copy link
Member

davidfowl commented Jul 4, 2012

Are you using azure websites?

@mfanto

This comment has been minimized.

Copy link
Author

mfanto commented Jul 4, 2012

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

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Jul 4, 2012

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

This comment has been minimized.

Copy link
Author

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

davidfowl commented Jul 8, 2012

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

@davidfowl davidfowl closed this Jul 8, 2012

@nberardi

This comment has been minimized.

Copy link
Contributor

nberardi commented Aug 12, 2012

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

This comment has been minimized.

Copy link
Member

davidfowl commented Aug 13, 2012

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

@devpascoe

This comment has been minimized.

Copy link

devpascoe commented Sep 22, 2012

any update on this?

@chevex

This comment has been minimized.

Copy link

chevex commented Oct 3, 2012

I too am having this issue. Any update?

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Oct 3, 2012

There's no update. Use longpolling for now.

@chevex

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Member

davidfowl commented Oct 3, 2012

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

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 2, 2012

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

@chevex

This comment has been minimized.

Copy link

chevex commented Nov 2, 2012

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

@davidfowl

This comment has been minimized.

Copy link
Member

davidfowl commented Nov 3, 2012

Nope

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