Tagged: c# elmah signalr elmahr

During the last two weeks I've been quite busy at work, so I haven't got many chances to go on implementing new on ElmahR, I've been just able to dedicate small time slices to the project and I used them to do mostly housekeeping. One of the things I did was to upgrade SignalR to version 0.5. SignalR is evolving quite fast so I wanted to keep in sync with it, I already knew that I would have had to fix a couple of things in my code because of breaking changes that 0.5 introduced, but those have been very easy. Everything was working fine so I deployed it on the demo site, but there something unexpected started to happen, the error feeds started getting filled by a recurring exception saying that 'ElmahR.ElmahRHub' hub could not be resolved. I immediately thought that something must have changed in SignalR, and that someone around the world was having a browser window open and pointing at the demo, but because that window was using an older version of SignalR javascript pieces the server was not able to understand those 'pollings', and therefore it started raising an InvalidOperationException.

It was already late night, so I just thought "those browser windows will be closed soon" and I did not worry that much, I just twitted about the new version and I went to bed. But the day after the errors were still popping up, and at a higher frequency, and every time I was connecting to check I could observe those exceptions bloating the error feeds.

David Fowler from SignalR team noticed it too and immediately pointed me at the problem, they effectively changed something in the SignalR protocol and so far there is no versioning mechanism for that, but they should work on that piece for the next versions. That is good news of course, but I still had the problem. I was really thinking that it wouldn't have last that much, but it's been a surprise to see how many people around have been using, and still use, the demo website to see how the project goes :) The bad part of this is that many of them are returning visitors with cached versions of the SignalR 'end point', making the application raise those exceptions.

The first thing I thought I could do to minimize the problem was to add an ELMAH filter to trap and discard those specific errors, but then I realized that another approach was probably more suitable to this case. If 'old' clients are connecting, I would really want to opt them out, so what I thought I might do was to 'cut' their path to the demo. When you use the hubs from SignalR, you must reference a dynamically generated javascript piece at signalr/hubs, but luckily since 0.5 of SignalR this path is customizable. So I decided to add myself the piece SignalR is still missing: protocol versioning, through the end point. How? Easy, I just customized the path to be signalr05/hubs. To achieve it I just had to do 2 things:

• go to global.asax.cs, and in the Application_Start handler add a route like this:

  RouteTable.Routes.MapHubs("~/signalr05");

• change the references (just 1 place actually) to the dynamic javascript path with the new one ('signalr05/hubs')

Now the demo works fine again, the errors have disappeared and the 'old' clients are blocked but they will work again as soon as they refresh the web page. This problem will be probably solved in future versions of SignalR, but for now this is a quick, clean and easy way to work around it. If you are planning to upgrade SignalR to 0.5 you may find this fix useful.