We deployed to a local development server and SOME users (not all) experience a signalr problem where the serverSentEvents won't connect and it falls back to long polling... normally that would be fine but it takes 5 seconds to fall back and the user experience is horrible.
The request gets a status of "canceled" in chrome's developer tools network tab and we ultimately end up connecting using signalr's longPolling. Here's the logging from signalr:
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Client subscribed to hub 'chat'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&clientProtocol=1.3'. jquery.signalR-2.0.0.js:75
[16:09:28 GMT-0500 (Eastern Standard Time)] SignalR: Attempting to connect to SSE endpoint 'http://mysubdomain.mydomain.com/signalr/connect?transport=serverSentEvents&con…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=6'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: serverSentEvents timed out when trying to connect. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: EventSource calling close(). jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: This browser supports SSE, skipping Forever Frame. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Opening long polling request to 'http://mysubdomain.mydomain.com/signalr/connect?transport=longPolling&connecti…bYUr2xEEBuw%3D%3D&connectionData=%5B%7B%22name%22%3A%22chat%22%7D%5D&tid=2'. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: Long poll complete. jquery.signalR-2.0.0.js:75
[16:09:33 GMT-0500 (Eastern Standard Time)] SignalR: LongPolling connected.
Once the client is finally connected via long polling, the site works fine but I still need to figure out why serverSentEvents is not working.
I can just disable serverSentEvents to get around this but it works for some people and not others so I'm wondering if there's some way to find out why it's failing for some people and not others.
Any advice on how to diagnose this?
It is taking 5 seconds to fallback from the Server-Sent Events transport because that is SignalR's default TransportConnectTimeout. This TimeSpan can be shortened via GlobalHost.Configuration.TransportConnectTimeout at app start.
There are many reasons SSE might fail. For example, there might be a router or firewall between your SignalR server and client that is coalescing or closing the chunked HTTP response that the Server-Sent Events transport relies on. It is difficult to know for sure what the exact cause of the SSE problem is when all I know is that the connection timed out.
Related
I'm using SignalR and SQLDependency. When there is a change on server, clients will be notified.
On Client side:
var job = $.connection.processLogHub;
$.connection.hub.logging = true;
$.connection.hub.transportConnectTimeout = 3000;
job.client.displayLastUpdate = function (displayLastUpdate) {
displayProcessLogChangeNotification(displayLastUpdate);
};
job.client.displayJobsLocked = function (realTimeLockedJobs) {
displayJobsLockedUnlocked(realTimeLockedJobs);
};
$.connection.hub.start().done(function () {
}).fail(function (e) {
alert('error signalr : ' + e);
console.log(e);
});
$.connection.hub.disconnected(function () {
console.log("$.connection.hub.disconnected");
setTimeout(function () {
console.log("restart");
$.connection.hub.start();
}, 1000);
});
Server side:
public class Startup
{
public void Configuration(IAppBuilder app)
{
app.MapSignalR();
GlobalHost.Configuration.TransportConnectTimeout = TimeSpan.FromSeconds(10);
}
}
ProcessLogHub class:
public class ProcessLogHub : Hub
{
public static void DisplayLastUpdate(string lastUpdateDate)
{
IHubContext context = GlobalHost.ConnectionManager.GetHubContext<ProcessLogHub>();
context.Clients.All.displayLastUpdate(lastUpdateDate);
}
public static void DisplayJobsLocked(IEnumerable<RealtimeLockedJob> realTimeLockedJobs)
{
IHubContext context = GlobalHost.ConnectionManager.GetHubContext<ProcessLogHub>();
context.Clients.All.displayJobsLocked(realTimeLockedJobs);
}
}
This code is sometimes working well. But sometimes suddenly it does not work anymore and give me the below log :
[15:12:27 GMT-0400 (Eastern Daylight Time)] SignalR: Client subscribed to hub 'processloghub'.
[15:12:27 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/JMT/signalr/negotiate?clientProtocol=2.1&connectionData=%5B%7B%22name%22%3A%22processloghub%22%7D%5D'.
[15:12:27 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/JMT/signalr/negotiate?clientProtocol=2.1&connectionData=%5B%7B%22name%22%3A%22processloghub%22%7D%5D'.
[15:12:28 GMT-0400 (Eastern Daylight Time)] SignalR: serverSentEvents transport starting.
[15:12:28 GMT-0400 (Eastern Daylight Time)] SignalR: This browser doesn't support SSE.
[15:12:28 GMT-0400 (Eastern Daylight Time)] SignalR: serverSentEvents transport failed to connect. Attempting to fall back.
[15:12:28 GMT-0400 (Eastern Daylight Time)] SignalR: foreverFrame transport starting.
[15:12:28 GMT-0400 (Eastern Daylight Time)] SignalR: Binding to iframe's load event.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: foreverFrame transport timed out when trying to connect.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: Stopping forever frame.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: foreverFrame transport failed to connect. Attempting to fall back.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: longPolling transport starting.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: Opening long polling request to 'https://pprd-entrypoint.bell.ca/JMT/signalr/connect?transport=longPolling&clientProtocol=2.1&connectionToken=ZtAV8xQcGKXtBY%2F2Ke3J12DeAYy3QQMirAWzzY4%2FeAW2oX1JeNkg6heTD%2BPUL8nnfgi6MoKl%2Fd1YliMMN6euu0YyLf7uBs02LQ7GsDb%2Fe9MDHrcD4SYESNHbfK3cZxzm&connectionData=%5B%7B%22name%22%3A%22processloghub%22%7D%5D'.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: Long poll complete.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: longPolling transport failed to connect. Attempting to fall back.
[15:12:41 GMT-0400 (Eastern Daylight Time)] SignalR: Fallback transports exhausted.
Error: No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization.
{
[functions]: ,
__proto__: {
[functions]: ,
__proto__: {
[functions]: ,
__proto__: null
},
message: "",
name: "Error"
},
description: "No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization.",
message: "No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization.",
name: "Error",
source: undefined
}
[15:13:36 GMT-0400 (Eastern Daylight Time)] SignalR: Stopping connection.
[15:13:36 GMT-0400 (Eastern Daylight Time)] SignalR: Fired ajax abort async = true.
[15:13:36 GMT-0400 (Eastern Daylight Time)] SignalR: LongPolling failed to connect.
[15:13:36 GMT-0400 (Eastern Daylight Time)] SignalR: Failed to parse server response while attempting to connect.
Unable to get property 'hub' of undefined or null reference
In the successful case the foreverFrame can connect to server:
[16:27:38 GMT-0400 (Eastern Daylight Time)] SignalR: foreverFrame transport connected. Initiating start request.
[16:27:38 GMT-0400 (Eastern Daylight Time)] SignalR: The start request succeeded. Transitioning to the connected state.
[16:27:38 GMT-0400 (Eastern Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332, keep alive timeout of 20000 and disconnecting timeout of 30000
Could you tell me why SignalR foreverFrame work on and off and how can I fix it?
Is it because I'm using 2 event for the notification?
Thank you
I am using SignalR - transport type longPolling. I am able to see the functionality working as expected. In realtime, I could see there are quite large number of signalR calls which is affecting performance heavily.
It seems, based on my analysis, longPolling creates connection and use it and close it. Then again the connection will be created on demand. I feel, this could be the cause of seeing lot of signalR calls at some point in time.
Could you please share your thoughts on this to resolve / avoid large number of SignalR calls?
When I tried to use foreverFrame as transport type, SignalR connection is not getting enabled. I could see the following error in console.
SignalR: Failed to connect using forever frame source, it timed out after 3000s
SignalR: Stopping forever frame
SignalR: No transport could be initialized successfully. Try specifying a different transport or none at all for auto initialization
Issue occurred when starting the Signalr Hub.
That appears to be default behavior for long polling based on the docs - Long polling does not create a persistent connection, but instead polls the server with a request that stays open until the server responds, at which point the connection closes, and a new connection is requested immediately. This may introduce some latency while the connection resets.
Your use of foreverFrame may not work because the transport is not available in the browser you are using.
I have yet to understand why anyone would force the transport to a specific one. Possibly, I have just not run into that scenario where it is required.
SignalR will handle the aspect of determining which transport to use with each client, which is one of it's great benefits.
I am really stumped on this one, I have a page that I am using to collect data on what methods are being called in my web application. When I run my application from visual studio, there is no problem, everything works great, all my server and client methods function as expected.
However, when I deploy this application to my webserver running IIS 7.5 on windows server 2008, R2 SP1 my client side methods do not consistently fire, everything looks like its running fine. but the triggering client event never happens.
Client Side Javascript:
var nlog = $.connection.centralHub;
$.connection.hub.logging = true;
$(function () {
var logTable = $("#logTable");
nlog.client.logevent = function (datetime, siteName, clientConId, logLevel, message, stack, eMessage) {
var tr = $("<tr>");
tr.append($("<td>").text(datetime));
tr.append($("<td>").text(siteName));
tr.append($("<td>").text(clientConId));
tr.append($("<td>").text(logLevel));
tr.append($("<td style='white-space: pre;'>").text(message));
tr.append($("<td>").text(stack));
tr.append($("<td>").text(eMessage));
logTable.append(tr);
};
nlog.client.test = function() {
$("#test").text("spit out a test");
}
$.connection.hub.start().done(function () {
nlog.server.initialMessage();
nlog.server.test();
}, 5000);
});
Server Hub methods:
Hub Method: CentralHub
public void InitialMessage()
{
string connId = Context.ConnectionId;
_clientTracker.InitalMessage(connId);
}
internal void InitalMessage(string connId)
{
Clients.All.logEvent(
DateTime.Now.ToString("F"),
"Harper Woods",
connId,
"info",
"Hub Started",
"No Message",
"No Message");
}
Google Console output from my IIS webserver
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Client subscribed to hub 'centralhub'
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&clientProtocol=1.3'.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'http://tcdev.citadelsystems.com/signalr/connect?transport=serverSentEvents&…7Hb0f69Gs1q&connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&tid=2'.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: EventSource connected.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000.
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.Test
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:14:22 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.Test
Google Console Output from Visual Studio 2013
[12:17:56 GMT-0400 (Eastern Daylight Time)] SignalR: Client subscribed to hub 'centralhub'.jquery.signalR-2.0.3.js:76
[12:17:56 GMT-0400 (Eastern Daylight Time)] SignalR: Negotiating with '/signalr/negotiate?connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&clientProtocol=1.3'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'http://localhost:32568/signalr/connect?transport=serverSentEvents&connectio…kMTNQps1lto&connectionData=%5B%7B%22name%22%3A%22centralhub%22%7D%5D&tid=3'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: EventSource connected.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.InitialMessage
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoking centralhub.Test
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Triggering client hub event 'logEvent' on hub 'CentralHub'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Triggering client hub event 'test' on hub 'CentralHub'.
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.Test
jquery.signalR-2.0.3.js:76
[12:17:57 GMT-0400 (Eastern Daylight Time)] SignalR: Invoked centralhub.InitialMessage
Ok, I finally was able to find a bit of information on what is going on here. It is where you set the dependency injection resolver for signalr, this MUST be done in the Application_Start() method of the Global.asax, you cannot rely on ninject web bootstrapper, and you cannot put it in the owin startup class like the example on ASP.NET site. It will not function predictably it will work sometimes, but you will miss messages.
I had this same exact issue. My SignalR Application would work perfectly in Visual Studio or Windows Local OS IIS. But when I deployed it to IIS 7.5 on Windows Server 2008 R2, the client methods wouldn't get invoked consistently. That was all because my application pool in deployment IIS server, had 10 working processors (i.e. Web Garden). This post helped me realize this and when I set the working processors to 1, It did the trick. Apparently this is by design.
From #AlexanderKöplinger:
This is by design. The two worker processes don't share state and clients will be distributed between them on a round-robin basis, which means 50% will connect to process A and 50% to process B. As the underlying SignalR message bus is in-memory by default, process A doesn't see messages from process B.
I'll set the working processor to 1 for now, but I'll try to find a way to make Web Garden work with SignalR.
Update:
Setting working processors to 1 is not good in regards of scaling. The SignalR team did provide us a way to make Web Garden work with SignalR and it's explained here. You have 3 methods to choose from and I decided to use the SQL server approach. The setup went smooth and easy and now SignalR is using SQL server as a backplane to share messages between different working processors.
At first sight, within your done() you are calling a Test method from the server which doesn’t exist or at least is missing. Removing this line could make it work.
I'm using ASP.NET MVC 4 and SignalR 2.1.1.
My website works great for most users in all browsers, but there is an error that only occurs for certain user on specific isp-networks.
The error is this:
The connection to ws://domain.com/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=78ZpJ007jmlLSBbVzDVbfpYahHsveD3x8%2Bc5PC9h%2FgeOz5zNgE8SaKWaQAasGNLe%2BvJeI6ux6IqW0E8WQWqP6Ps%2FXjc8WPbG7G47oHSxRSx7nVj0leVa1DdXzEXnLQ%2BA&connectionData=%5B%7B%22name%22%3A%22homehub%22%7D%5D&tid=4 was interrupted while the page was loading.
For the same users receiving this error, logging in the internet using a different network (while same browser / computer / cellphone) fixes the problem.
Up until now I only saw questions about this error that points the problem to the browser, however in my case, using the same browser with a different network fixes the problem.
Any chance any of you knows how to fix this?
UPDATE 1:
I noticed that client methods actually works, it's the server methods that don't work.
What do I mean?:
I have a list of online users, and upon user entering & exiting the site, a signalr client method that updates the list of usernames is called:
hub.client.addOnlineMember = function (member) {
var newMember = addMember(member);
memberList.append(newMember);
};
hub.client.removeOnlineMember = function (member) {
var newMemberId = '#' + member;
$(memberListName + ' ' + newMemberId).remove();
};
However when trying to load messages from the server, it's functions don't work:
$('#LoadMore').click(function () {
hub.server.loadTopics(page);
});
UPDATE 2:
I added logging:
$.connection.hub.logging = true;
Here are the findings:
The connection to ws://domain.com/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=rR8%2BSK%2BC%2FtuzPqIGKgPrUNORzBz2kP0WUmXJsURP70Zsj6RK1fOi5tUN1UGEQPntGwoEvwinMkPCXRTyliLwzfLoOBl%2BkCWoBAkAqIFYaDVk3X1MG8dQERl8Or%2F4%2Filp&connectionData=%5B%7B%22name%22%3A%22hub%22%7D%5D&tid=6 was interrupted while the page was loading. jquery.signalr-2.1.1.min.js:8
Synchronous XMLHttpRequest on the main thread is deprecated because of its detrimental effects to the end user's experience. For more help http://xhr.spec.whatwg.org/ jquery-2.1.1.min.js:4
"[16:21:50] SignalR: Stopping connection." jquery.signalr-2.1.1.min.js:8
"[16:21:50] SignalR: Closing the Websocket." jquery.signalr-2.1.1.min.js:8
no element found abort:1
"[16:21:50] SignalR: Fired ajax abort async = false." jquery.signalr-2.1.1.min.js:8
"[16:21:50] SignalR: Stopping the monitoring of the keep alive." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: Client subscribed to hub 'hub'." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: Negotiating with '/signalr/negotiate?clientProtocol=1.4&connectionData=%5B%7B%22name%22%3A%22hub%22%7D%5D'." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: Connecting to websocket endpoint 'ws://domain.com/signalr/connect?transport=webSockets&clientProtocol=1.4&connectionToken=bkg5ksXTUdzl9GrShmLqEyUbeG9SMDBaiccbH2prQ4t1mPmoOutKqj9gvgkd9vveTnIKhK0cMHYZ8NOrS4pemaLmwOb5TmNJzGEiPAUXrknuIhxtUSqmNmL255MIFdwc&connectionData=%5B%7B%22name%22%3A%22hub%22%7D%5D&tid=2'." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: Websocket opened." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: webSockets transport selected. Initiating start request." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: The start request succeeded. Transitioning to the connected state." jquery.signalr-2.1.1.min.js:8
"[16:21:51] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000." jquery.signalr-2.1.1.min.js:8
"[16:23:05] SignalR: Triggering client hub event 'addOnlineMember' on hub 'hub'." jquery.signalr-2.1.1.min.js:8
"[16:23:25] SignalR: Triggering client hub event 'removeOnlineMember' on hub 'hub'." jquery.signalr-2.1.1.min.js:8
"[16:23:42] SignalR: Invoking hub.LoadTopics" jquery.signalr-2.1.1.min.js:8
As you can see, client methods works great. Server method is being invoked but nothing happens.
Logging signalr on a working isp network:
"[17:03:40] SignalR: Invoking hub.LoadTopics" jquery.signalr-2.1.1.min.js:8
"[17:03:41] SignalR: Triggering client hub event 'addTopicToHome' on hub 'hub'." jquery.signalr-2.1.1.min.js:8
"[17:03:41] SignalR: Triggering client hub event 'incrementPage' on hub 'hub'." jquery.signalr-2.1.1.min.js:8
"[17:03:41] SignalR: Invoked hub.LoadTopics" jquery.signalr-2.1.1.min.js:8
UPDATE 3:
Upon uploading my project to an IIS 7.5 server, the code works for all ISP networks. Seeing as IIS 7.5 does not support Websockets, protocols such as server-sent-events, long polling and forever frame (depends on the browser) are initiated successfully.
However, I don't know the reason why the IIS 8 server is not initiating a working protocol upon realizing websockets don't work, it's what signalr does, isn't it?
I made contact with my hosting provider, they think the problem has something to do with an unsupported SSL key on the server. This SSL issue still hasn't been fixed by them so there's no way to be sure that's really the problem. Do you think this might be it?
Anyway, still no success in finding an answer.. please help.
Okay its been so long and I was hoping to get help by now, but never mind I mannaged it.
First:
The guys at signalr's channel in Jabbr suggested me to try surfing the website using SSL in hopes it would solve the problem.
I'm afraid I did not have the chance to check that :(
But in case any of you meets the same issue and gets to use SSL approach to solve it, I would deffinitly love to here about it!
And to my answer:
I am taking the user IP and testing if it's in any of the problematic ISP subnets.
If it is, I'm passing my view a parameter, lets say:
bool disableWebsockets = True/False;
If its true, I'm passing signalr a list of transport protocols that does not include websockets. If false - the list does include websockets.
That's it.
function signalrTransportList(wsState) {
if (disableWebsockets == "False") {
var list = ['webSockets', 'serverSentEvents', 'longPolling', 'foreverFrame'];
}
else {
var list = ['serverSentEvents', 'longPolling', 'foreverFrame'];
}
return list;
}
...
...
$.connection.hub.start({ transport: signalrTransportList(wsTransport) })
I know it's yet another post relating to this problem :)
I'm trying to rewrite my project to make use of SignalR Self-Host library (as per this tutorial), but can't get passed this error now.
I initialise the connection as follows:
$.connection.hub.url = "http://localhost:8182/signalr";
$.connection.hub.logging = true;
var connection = $.connection.hub.start();
console.log(connection.state());
connection.done(function () {
console.log(connection.state());
[...] // initialising viewmodels in here...
});
When the first viewmodel is initialised I get the error as per the thread subject:
[17:29:14 GMT+0100 (GMT Daylight Time)] SignalR: Auto detected cross domain url. jquery.signalR-2.0.3.js:76
[17:29:14 GMT+0100 (GMT Daylight Time)] SignalR: Negotiating with 'http://localhost:8182/signalr/negotiate?clientProtocol=1.3'. jquery.signalR-2.0.3.js:76
pending main.js:218
[17:29:14 GMT+0100 (GMT Daylight Time)] SignalR: Attempting to connect to SSE endpoint 'http://localhost:8182/signalr/connect?transport=serverSentEvents&connection…pdQlpKjRBpUhB0PY4itVfHasSmixQAAAB0HA7hA9gYDflrhGockG%2FZR55tLg%3D%3D&tid=1'. jquery.signalR-2.0.3.js:76
[17:29:14 GMT+0100 (GMT Daylight Time)] SignalR: EventSource connected. jquery.signalR-2.0.3.js:76
[17:29:14 GMT+0100 (GMT Daylight Time)] SignalR: Now monitoring keep alive with a warning timeout of 13333.333333333332 and a connection lost timeout of 20000. jquery.signalR-2.0.3.js:76
resolved main.js:220
Object {getAccountActions: function, getIncidentActionCount: function, getIncidentActions: function, refreshAccountActions: function, refreshActions: function…}
IncidentAction.js:12
Uncaught Error: SignalR: Connection must be started before data can be sent. Call .start() before .send()
I console.log connection state after connection.done and is clearly showing as resolved.
Also in the first viewmodel I initialise, I console.log connection.server and all my server methods are visible there, as per the snippet above.
Server side code:
class Program
{
static void Main(string[] args)
{
string url = "http://localhost:8182";
using (WebApp.Start(url))
{
Console.WriteLine("Server running on {0}", url);
Console.ReadLine();
}
}
}
Any suggestions, why I am getting this error even though the connection is 'resolved'?
Edit: Originally I moved my Owin Startup class on the server to a different project within my solution and I assume this caused the problem. When I put it in my signalR self host project, the error is gone
The connection state should be connected
Try it like this :
$.connection.hub.start().done(function () {
console.log(connection.state());
}) .fail(function (error) {
console.log('Invocation of start failed. Error:'+ error)
});