+972 52-548-6969
How SignalR killed RavenMQ
Close to a year ago, I posted about RavenMQ for the first time, discussing the ideas behind it and what we intended to do with it. We even produced a private beta group to started testing it, but we never had enough resources to be able to make this more than an interesting project.
What I wanted is to make this a product, but that requires a lot more effort. Recently I started looking at SignalR as a way to undercut the amount of work that would be required to build RavenMQ. And the more that I looked at SignalR, the more uncomfortable I felt. SignalR seems to be a pretty good fit for the sort of things that I was thinking about for RavenMQ.
More than that, the longer that I dug into it, the more I liked it. The problem is that I feel that with SignalR in existence, the main reason for RavenMQ is now no longer there. Oh sure, we can build it, we can even base it on SignalR for wire compatibility, but I don’t feel that we can really generate a good enough value to create a viable product. At least, not one that I would feel comfortable charging for.
Given that, I am going to discontinue development on RavenMQ. If you were part of the RavenMQ beta group, you are strongly encouraged to look at SignalR and check whatever you can use that instead.
Comments
Can you elaborate on "the sort of things"?
Why not open source it and let the community decide its fate?
Are you planning to write your own SignalR.ScaleOut with RavenDB instead of the sql server implementation that is currently in the SignalR project?
+1 for what Marcus Swope said
Seems like SignalR is only built to run as an IIS web app, so can't be used inside an windows service. Or am I mistaken?
I really need something like RavenMQ, I was excited when you started to work on it as it fills a void that no other framework fills, but then you sort of left it (I guess to spend more time with raven db).
In my current project we built a simple pub/sub solution using WCF callback channels, but something like ravenmq where clients can subscribe to dynamic "entity channels" is exactly what we need. So if you can build that on top of signalR it would be very useful, but I think the limitation to only use it behind IIS is pretty limiting.
@Torkel The default scenario for SignalR is using it with IIS, but it's not tied to IIS (think of IIS as the only host implementation). That said, we haven't done any other work (yet) to make SignalR work on other "hosts" but it's not out of the question.
Or should it be "How Hibernating Rhinos killed RavenMQ"? I have to wonder if Ayende pre-HR would have been deterred just because it might not be a "viable product".
I don't mean to debate the history / use of RavenMQ. I just want to point to the possible warning signs that the one thing you so highly value, "passion" for software, as a motivator for development can easily be overridden by the desire for the almighty $.
@Steve,
Well said, Steve, but I'm afraid to the wrong target. HibeR in general and Ayende in particular are making "SOFT" ware. It's soft, not hard - anything could be done, there are no fundamental physical reasons not to. They are doing "it" right, so the only remaining question is are they doing the right "it"?
No one knows the answer, may be there is no absolute answer. Any criteria could be used - $ or fun - doesn't matter. Would it sound better if he'd say: "SignalR already did it, no fun to repeat their work"?
Still, I like the "overridden motivator" - nice name for a method :) Where can I use it? In Boo? :)
Steve, Ayende already has some checkins to a fork of SignalR. While you find clever ways to question his values, he is writing software.
Torkel, I think that pretty much everything you could have done with RavenMQ, you can do with SignalR, most especially, the issue of entity channels is handled quite nicely by SignalR. That was the main motivation for creating RavenMQ in the first place, after all. When that is being handled, I don't really see a need to go forward with RavenMQ
@Mike: "SignalR already did it, no fun to repeat their work" Yup, that would have sounded a lot better. My only point was was on the devotimating factors being a viable product and not being able to charge for it. Ayende's contributed more pro-bono code out there than I probably will in my lifetime so my comment wasn't critical of his decision, but I was just curious / concerned that passion may end up becoming an overridden motivator as you put it. :)
@fschwiet: .... and you spend your time trolling.
Steve, I make a strong distinction between code I write for fun and code I write for product. Now, in some cases I get to choose what I work on, so I chose something fun, but there are a lot of differences between pet projects & products. And I am trying to figure out what products we can make that would be fun to work on.
The very fact that I didn't do much with RavenMQ for almost a year tell me that I am not really interested in it any longer. Which means that it gets a very cold treatment.
You don't have to take all opportunities in life, just the best ones. So +1 for killing it.
My love for socket.io and node is mainly because of the fact that they are very lightweight. SignalR takes a thread per connection (right?) but node only takes a few bytes per connection.
I have created event-hubs based on asynchttphandler in .NET before and it really gets ugly when thousands of users are logged-in at the same time with long lasting connections. The web server can't handle it and IIS starts taking seconds for delivering static files.
Scott Hanselman and you say it is scalable, but how so? Will it distribute requests to different servers or will you have to take care of that yourselves. I would like to see a performance test of SignalR before leaving node.
I would love to see a RavenMQ actually, I haven't heard about it until today but if it would "just work" the same way RavenDB does (both for easy setup and deployment but also for replication and sharding). A RavenMQ with same principles as node (no threading) but with C# instead of Javascript. It would rock.
It could very well be that someone have made a performance test of SignalR if so I would love to read it!
Thanks again,
Christian
Christian, No, it doesn't take a tread for connection, no.
Comment preview