SignalR not working - not finding hubs - Probably due to assembly loading taking place "too late"

Topics: Administration, Core, Customizing Orchard, General, Nederlands (Dutch), Troubleshooting, Writing modules
Feb 14, 2014 at 8:08 PM
We're using NGM.SignalR, NGM.Wave (and of course NGM.Forum), however we cannot get our hubs registered.

After a lot of trouble with the various versions of Microsoft.Owin, Microsoft.Owin.Security, Microsoft.Owin.Host.SystemWeb, Microsoft.AspNet.SignalR, etc. etc. we finally got to a point where we could start Orchard with the 3 modules.

However, the hub (WaveHub) does not get found.

We've investigated this a bit and we found out that the module gets loaded too late. And we also found out that SignalR only maps IHub classes (generally that would be a class that extends "Hub") in the current assembly. Modules are assemblies separated from Orchard.Web, so they won't get loaded automatically, unless Orchard does. And when Orchard does, it's too late.

Also, the modules will have a dependency on NGM.SignalR (or Proligence.SignalR for that matter), so that assembly will be loaded first. That's also the assembly that loads the Hub-routes. So at that time, the assemblies containing the hubs will probably not be loaded yet.

Anyone got any luck getting SignalR to work well with Orchard, without doing crazy things to register the hubs?
We have now managed to get it to work when we specifically add a reference to NGM.Wave (containing a hub), or by loading the NGM.Wave assembly into the CurrentDomain. But that's not something we would want to use in a production environment.
Feb 18, 2014 at 3:51 PM
I couldn't get NGM.SignalR to work, didn't seem to register anything. so gave up on that.

Moved onto using Proligence. This one uses an old version of signalr so you have to make sure you copy the dlls from the bin in proligence directly into your new module, don't install from nuget or anything, that fucks everything up. I think you also need a reference in your module to proligence as well or it gets confused.

That all worked fine for me, haven't tried persistent connection, only hubs, am using it to broadcast alerts to users on the site, seems to be working okay. fingers crossed. Got a hell of a lot of errors during development where Collection was of a fixed size. at shellContext.LifetimeScope.Dispose();, haven't seen them in the live environment really, except when I enable a new module but a quick refresh gets rid of it. Don't know much about the internals of signalr/orchard to really workout why it is happening. Possibly upgrading signalr would fix it... ^_^
Feb 18, 2014 at 6:59 PM
Hey Guys, I am the Author of NGM.SignalR. Can you let me know what version of Orchard you are having problems with?
Feb 19, 2014 at 8:00 AM
I've seen the shellContext.LifetimeScope.Dispose() exception too. "Collection was of a fixed size" is the message we're getting too, indeed.
Also, sometimes it takes very long to load the hub context (we're using this as an OnUpdated-contenthandler). It seems it's like reloading the appdomain.

But this also may be due to our "weird" setup (we're referencing all projects that contain IHub-implementations in Orchard.Web, otherwise it's not finding those hubs).

I'm trying Proligence.SignalR now, but no luck so far. I've only tried it for a few minutes though. One thing I noticed is that it used to not find our hubs, but now instead it does. Without having a reference in Orchard.Web.

Thanks for your post Hazza, I'm glad I'm not the only one with these problems. The DLL-part seems to be important. When we're using nuget to setup everything, it gets kinda screwed up. We're now at some point (in a branch, with NGM.Wave as a reference in Orchard.Web) where we can actually use the SignalR stuff that NGM.Wave provides. But we did have to fix the DLLs. (SignalR dlls at 2.0.2, Microsoft.Owin dlls at 2.0.1, Owin dll at 1.0).
Feb 19, 2014 at 12:01 PM
Edited Feb 19, 2014 at 12:01 PM
When using Proligence.SignalR, it seems to hang at:
            public HttpContextScopeImplementation(IEnumerable<IWorkContextEvents> events, ILifetimeScope lifetimeScope, HttpContextBase httpContext, object workContextKey) {
                _workContext = lifetimeScope.Resolve<WorkContext>();
                httpContext.Items[workContextKey] = _workContext;

                _disposer = () => {
                    events.Invoke(e => e.Finished(), NullLogger.Instance);

And then the liftimeScope.Dispose()-call.

I can't find any Autofac source code for 3.0.0 (which is what Orchard 1.7.1 is using), so I can't debug this. I'm quite interested to see what it is doing there, as it's taking very long (infinitely long to be exact).

This is only when SignalR needs to send a message to the client.
Feb 19, 2014 at 1:57 PM
Thanks guys for the feedback. I haven't updated Proligence.SignalR module for a while so there is a chance that it got broken in the meantime.

I'm currently working on updating it for Orchard 1.8 and .NET 4.5 to be able to use SignalR 2.0. I don't want to maintain two versions so any fixes/updates will apply to the .NET 4.5 version only (unless it's something that can be back-ported easily). Will keep you posted in this thread.
Feb 19, 2014 at 2:48 PM
@hkui Hmm, mine doesn't hang there. Is that with your custom module? Does it do that with the samples included with Proligence?

@pszmyd would be cool if you could keep us updated, signalr 2.0 would be awesome :) I really need to spend ages going through your code and looking up all the methods you used to hook up signalr. all a bit too low level for me really ^_^

@Jetski5822 I tried it with 1.7.2, it didn't work out of the box and I didn't really understand anything you had done to wire up signalr so I ran away. Sorry I cant be more help
Feb 20, 2014 at 10:44 AM
Edited Feb 20, 2014 at 11:02 AM
It doesn't do that with the samples provided in the Proligence SignalR module.

But, the problem is only when we look up a HubContext and call a SignalR-method on it, from outside of the hub (through the hubcontext). None of the samples do that.

So, having a sample that shows that would be nice to include. I think that is one of the most common reasons to be wanting SignalR: Interaction with parts of the Orchard CMS. We're using it in an OnUpdated-handler.

The NGM.SignalR module works fine regarding that aspect. The NGM.Wave module shows that.

So yes, there are multiple issues with the SignalR modules that are available now. I understand it's very hard to fix these issues. I also understand it's hard to keep the modules up-to-date.
But it's nice that we can share our experiences in this topic and make the 2 modules even better.

I've however seen an issue where it takes very long to load the edit-page (Admin/Contents/Edit/1), when we send a message to Clients.All from within an OnUpdated-handler. In the same way NGM.Wave does.
Feb 27, 2014 at 8:58 AM
Hey guys, I just updated Proligence.SignalR to latest SignalR 2.0.2. It requires Orchard 1.x and .NET 4.5. Could you please check it out and see if any of those issues still exist?

The only issue with finding hubs I can think of is that they have to exist within the module project and related feature has to be enabled. IHub implementations coming from external dlls won't be discovered - I'm purposefully scanning types exported by enabled features only, not the whole AppDomain.
Feb 27, 2014 at 9:23 AM
We unfortunately are still running production on 1.6 and development on 1.7.2. Although I'm vaguely planning to move it all into 1.8 when it gets released, so I will definitely check out your latest update then.

Anyway, thanks for responding and updating it, appreciate all the effort you put it :)
Feb 27, 2014 at 10:20 AM
@pszmyd: Did you also test calls from outside of a hub? Using the IHubContext<IHub>?
That was something that wasn't working properly for us.

Will be checking out your module today. Thanks for the update!