Distributed signals for web farms

Topics: Customizing Orchard, Writing modules
Aug 23, 2012 at 12:53 PM

So I've been working on the second level caching provider for Azure and I've come to some roadblocks, so I switched to a distributed cache instead. There are some issues with it with the way that Orchard works at the moment, but it did give me an insight into the signals mechanism.

I saw that Piotr has been working on a SignalR implementation, but from first glance it looks like the wrong tool for this particular job. Please correct me if I'm wrong!

I've had a few issues that would have been solved if the signals propagated to all instances, so I think I'll start with this.

My idea:

  • Monitor the role for any instances being added or removed
  • Keep a list of instances
  • Create a web api to trigger a signal
  • Override the default signal provider to additionally broadcast a message to all other instances' web apis when a signal is triggered

Is this on the right track? I'm sure I'm not the only person that would benefit hugely from this.

Aug 24, 2012 at 8:42 AM

So I have a module @ 


It's untidy and a proof of concept for now.

It should monitor azure instances and then when a signal is triggered, trigger that signal to all other instances.

I haven't tested it on a live Azure deployment, and I haven't tested modifying the number of instances. 

It uses a tcp connection from each server to each other server, and doesn't re-use incoming connections to send data. It keeps the connections open though, and just sends messages when they are required. 

Some potential issues...

  • It assumes all signals are strings. I would like to test it on all modules shipped with orchard and modify it if it ceases to work. 
  • I read that there were problems creating tcp connections on live azure instances. It was written in 2010, so I'm hoping that the issue is gone now.

Any feedback/testing/suggestions welcome.