7

For some reason, SignalR will just stop calling client methods after a short period of time (about 1 hour or less I estimate). I have a page that shows Alerts... a very simple implementation. Here's the Javascript:

$(function () {

    // enable logging for debugging
    $.connection.hub.logging = true;

    // Declare a proxy to reference the hub. 
    var hub = $.connection.alertHub;

    hub.client.addAlert = function (id, title, url, dateTime) {
        console.log(title);
    };

    $.connection.hub.start().done(function () {
        console.log("Alert Ready");
    });
});

If I refresh the page, it works again for about an hour, then will stop calling the client event addAlert. There are no errors in the log, no warnings. The last event in log (other than the pings to the server) is:

[15:18:58 GMT-0600 (CST)] SignalR: Triggering client hub event 'addAlert' on hub 'AlertHub'.

Many of these events will come in for a short while, then just stop, even though the server should still be sending them.

I am using Firefox 35.0.1 on Mac and SignalR 2.0.0.

I realize that a work-around is to force a page refresh every 10 mins or so, but I'm looking for a way to fix the root cause of the problem.

I enabled SignalR tracing on the server. I created an "alert" on the server after a fresh refresh of the Alert page and the alert came through. I waited about 10 mins and I tried it again, and it failed to come through. Here's what the logs read (sorry for the verbosity, not sure what was relevant):

SignalR.Transports.TransportHeartBeat Information: 0 : Connection b8b21c4c-22b4-4686-9098-cb72c904d4c9 is New.
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9)
SignalR.Transports.TransportHeartBeat Verbose: 0 : KeepAlive(b8b21c4c-22b4-4686-9098-cb72c904d4c9)

There are dozens more of the SignalR.Transports.TransportHeartBeat messages, but nothing else.

Swisher Sweet
  • 769
  • 11
  • 33
  • 1
    Have you set logs in the hub on the server side to see whether your client is disconnecting prior to the stopped activities? – Steve Mitcham Feb 24 '15 at 13:37
  • I have not. I'll do that and post the results. Thanks. – Swisher Sweet Feb 24 '15 at 13:51
  • Apart from logs. What transport are you using and are you going through proxies? If so, have you tried using https? – Pawel Feb 24 '15 at 18:22
  • I am using WebSockets. I am not going through proxies and I have not tried HTTPS, but will. – Swisher Sweet Feb 24 '15 at 18:49
  • 2
    Is it possible this is coming from your server, resetting the application pool? I've not experienced this myself, but I do know that SignalR will not keep that connection alive (in terms of resetting the app-pool reset timeout). I think by default a session state is 20 mins (?) and app pool is 90 minutes? I can't remember exactly. I guess - maybe look to what the server is doing. Is the app pool being refreshed, giving everyone all new connections? – Jason Feb 25 '15 at 21:11
  • The app pool is being refreshed, but only every 4 hours. I estimate that the client stops getting called just about 15 minutes after a page refresh. – Swisher Sweet Feb 26 '15 at 18:19

3 Answers3

2

i think theres a timeout of default 110 seconds for signalr. Can you try signalr disconnected event to reconnect it back.

$.connection.hub.disconnected(function () {
            setTimeout(function () {
                startHub();
            }, 5000);
        });

and in startHub() you can start connection again.

reference : https://github.com/SignalR/SignalR/issues/3128

and How to use SignalR events to keep connection alive in the right way?

Community
  • 1
  • 1
Chaitanya Gadkari
  • 2,669
  • 4
  • 30
  • 54
  • I'll give that a shot and post the results. Thank you. – Swisher Sweet Feb 24 '15 at 13:56
  • 1
    The 110 secs time out is only used for long polling request to prevent proxies from breaking the long running HTTP requests. The poll request will be closed after 110 seconds and a new poll request will be created and this should not cause reconnects/disconnects since this is how long polling works. This timeout does not apply to other transports (OK, I am not sure about the forever frame transport) – Pawel Feb 24 '15 at 18:21
  • any progress? I'm curious now. does app pool recycling affect this as stated by Jason. – Chaitanya Gadkari Feb 26 '15 at 05:22
  • This did not fix the problem. App pool is not recycled but every 4 hrs, so it is not affecting this. Posted server logs if you are interested. I don't understand them. – Swisher Sweet Feb 26 '15 at 22:30
0

As it turns out the problem was the way I was handling the AlertHub connections. I am using Enterprise Library Caching to store connections backing the AlertHub, and I was expiring the cache entries 20 minutes after they were created. Ergo, when the server called the client method, no errors where reported because there were no client(s) to send the message(s) to.

I have since increased the cache expiration to a reasonable value, which solved the problem.

Swisher Sweet
  • 769
  • 11
  • 33
  • Can you post the code / file where you did that? I think I have the same issue. Much obliged. – toddmo Apr 11 '15 at 22:40
-3

You can refresh page if client is inactive, no mouse movement (in about every 15-30 min). I had same problem and solved it that way. That was nasty workaround but later i forgot about it and never fixed it completly ;)

RandomBoy
  • 464
  • 1
  • 4
  • 15