I'm keen to get up and running with SignalR as it looks just right for my needs.
Unfortunately, when following the chat example I don't get very far at all. After some time looking into the issue I have discovered that the call to RouteTable.Routes.MapHubs() fails in the Application_Start() method of global.asax.cs. In fact, it causes
IIS to crash - no exception is thrown. This occurs whether I use the VS Development Server, IIS Express or the local IIS.
I have noticed that the folder ~/signalr is never created in the root of my project. I am wondering if it is some sort of permisions issue wherein the folder cannot be created.
I am using VS2010 on windows 8. IIS8 is installed and I have added "WebSocket Protocol" to the Windows Features.
Does anyone have any ideas on how to resolve this?
[EDIT] Some more information: I have just worked through the Self hosted example at http://architects.dzone.com/articles/push-data-real-time-signalr and that works fine.
I just upgraded a project (a typical mvc 4 application) to rc2 and now I'm experiencing the same issue as the original poster. IIS Express is crashing about 75% of the time I debug the project. (win 7 x64 vs2012) It will hang on the call to MapHubs().
I'm not prepared yet to call this a bug in signalr however, investigating now. Seems to be working when I publish it to a server 2008 box with iis 7...
No exception actually. The debug session will continue up to the point in which maphubs is called and then hang. I typically cancel the process pretty quickly but I have let it "hang" for 10+ minutes with no joy. I do want to stress that I haven't fully
investigated the issue and would hate to waste precious time if it ends up being some sloppy code of mine leftover from working with the previous signalr versions. I'm looking into it now and will report back what I discover. I did also just notice a similar
issue on github (1335), might be related.
I should say that the symptom I called "crash" in the original post was really:
VS detaching from the debug session when MapHubs() was called,
No exception being thrown,
The browser (firefox) display a "server not available" message
I apologise if I used the word "crash" in a misleading way. I know how annoying that can be.
I have been able to resolve the problem by completely reinstalling the operating system from Windows 8 Preview to the release version of Windows 8. I then installed VS 2012 and IIS8 and SignalR rc2, I ensured that the call to MapHubs() occurred earlier in
Application_Start() (in fact it is now the first call). At this point it all worked except that the transport being used was not WebSockets. To get WebSockets transport up and running I ensured that .NET 4.5 framework was being used (config file changes only)
and double checked that IIS has WebSockets installed (using "Turn Windows Features on or off"). Then it all worked!
All in all the technology looks great but I am not so sure about the quality of the internal error handling. Perhaps the issue is at a lower level that the library itself?
Rebooting was the first thing I tried. It hasn't solved the problem for me. I've also moved the maphubs call to the very first line of the Application_Start method as the original poster suggested but am still experiencing the problem. I haven't tried
wiping my machine, I hope it doesn't come to that...
I can agree with the original poster's characterization of the 'crash', its the same thing thats happening on my machine.
Build the source, add a reference to your project and debug that line (MapHubs will call into that code). The code was supposed to detect the hang (the hang happens for an unknown reason) and bail out of the performance counter initialization.
Unfortunately the problem no longer appears on my new build so I will not be able to debug the problem.
Whilst it is possible that the issues is with the performance counter issue you mention above, it may not be. I say this because the symptom I saw was the VS 2012 debugger disconnecting from IIS/Development Server pretty much straight away. There was not
a long wait/timeout as part of the symptom.
jamesbdarcy
0 Points
8 Posts
Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 11, 2013 03:15 AM|LINK
Hi all
I'm keen to get up and running with SignalR as it looks just right for my needs.
Unfortunately, when following the chat example I don't get very far at all. After some time looking into the issue I have discovered that the call to RouteTable.Routes.MapHubs() fails in the Application_Start() method of global.asax.cs. In fact, it causes IIS to crash - no exception is thrown. This occurs whether I use the VS Development Server, IIS Express or the local IIS.
I have noticed that the folder ~/signalr is never created in the root of my project. I am wondering if it is some sort of permisions issue wherein the folder cannot be created.
I am using VS2010 on windows 8. IIS8 is installed and I have added "WebSocket Protocol" to the Windows Features.
Does anyone have any ideas on how to resolve this?
[EDIT] Some more information: I have just worked through the Self hosted example at http://architects.dzone.com/articles/push-data-real-time-signalr and that works fine.
James
davidfowl
Contributor
2699 Points
611 Posts
Microsoft
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 15, 2013 05:10 PM|LINK
Can you try using the new rc2 Package?
Senior SDE, ASP.NET Team, Microsoft
flavorful
Member
94 Points
22 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 20, 2013 05:55 AM|LINK
I just upgraded a project (a typical mvc 4 application) to rc2 and now I'm experiencing the same issue as the original poster. IIS Express is crashing about 75% of the time I debug the project. (win 7 x64 vs2012) It will hang on the call to MapHubs(). I'm not prepared yet to call this a bug in signalr however, investigating now. Seems to be working when I publish it to a server 2008 box with iis 7...
davidfowl
Contributor
2699 Points
611 Posts
Microsoft
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 20, 2013 05:59 AM|LINK
Crashing with what exception?
Senior SDE, ASP.NET Team, Microsoft
flavorful
Member
94 Points
22 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 20, 2013 08:29 AM|LINK
No exception actually. The debug session will continue up to the point in which maphubs is called and then hang. I typically cancel the process pretty quickly but I have let it "hang" for 10+ minutes with no joy. I do want to stress that I haven't fully investigated the issue and would hate to waste precious time if it ends up being some sloppy code of mine leftover from working with the previous signalr versions. I'm looking into it now and will report back what I discover. I did also just notice a similar issue on github (1335), might be related.
Ysgrathe
Member
4 Points
2 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 20, 2013 02:23 PM|LINK
I dont know if this helps anyone:
I had the same problem this morning running the rc1 (which was previous working fine yesterday and nothing changed)
I updated to rc2, same problem
I just rebooted the development machine, and everything is fine now.
jamesbdarcy
0 Points
8 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 20, 2013 09:01 PM|LINK
Hi all. This is the original poster here.
I should say that the symptom I called "crash" in the original post was really:
I apologise if I used the word "crash" in a misleading way. I know how annoying that can be.
I have been able to resolve the problem by completely reinstalling the operating system from Windows 8 Preview to the release version of Windows 8. I then installed VS 2012 and IIS8 and SignalR rc2, I ensured that the call to MapHubs() occurred earlier in Application_Start() (in fact it is now the first call). At this point it all worked except that the transport being used was not WebSockets. To get WebSockets transport up and running I ensured that .NET 4.5 framework was being used (config file changes only) and double checked that IIS has WebSockets installed (using "Turn Windows Features on or off"). Then it all worked!
All in all the technology looks great but I am not so sure about the quality of the internal error handling. Perhaps the issue is at a lower level that the library itself?
flavorful
Member
94 Points
22 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 21, 2013 01:36 AM|LINK
Rebooting was the first thing I tried. It hasn't solved the problem for me. I've also moved the maphubs call to the very first line of the Application_Start method as the original poster suggested but am still experiencing the problem. I haven't tried wiping my machine, I hope it doesn't come to that...
I can agree with the original poster's characterization of the 'crash', its the same thing thats happening on my machine.
davidfowl
Contributor
2699 Points
611 Posts
Microsoft
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 21, 2013 03:00 AM|LINK
I'm pretty sure the issues everyone is seeing is this:
https://github.com/SignalR/SignalR/issues/1158
Since you can reproduce the issue I'm going to have to ask one of you guys to help debug the problem. The relevant code is in
https://github.com/SignalR/SignalR/blob/master/src/Microsoft.AspNet.SignalR.Core/Infrastructure/PerformanceCounterManager.cs#L253
If you don't know git you can get the sources here:
https://github.com/SignalR/SignalR/archive/dev.zip
Build the source, add a reference to your project and debug that line (MapHubs will call into that code). The code was supposed to detect the hang (the hang happens for an unknown reason) and bail out of the performance counter initialization.
Senior SDE, ASP.NET Team, Microsoft
jamesbdarcy
0 Points
8 Posts
Re: Call to RouteTable.Routes.MapHubs() crashing IIS
Jan 24, 2013 04:26 AM|LINK
Hi David.
Unfortunately the problem no longer appears on my new build so I will not be able to debug the problem.
Whilst it is possible that the issues is with the performance counter issue you mention above, it may not be. I say this because the symptom I saw was the VS 2012 debugger disconnecting from IIS/Development Server pretty much straight away. There was not a long wait/timeout as part of the symptom.