﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on How SignalR killed RavenMQ</title><description>Christian,
No, it doesn't take a tread for connection, no.
</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment15</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment15</guid><pubDate>Thu, 22 Sep 2011 05:11:01 GMT</pubDate></item><item><title>Christian Landgren commented on How SignalR killed RavenMQ</title><description>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</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment14</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment14</guid><pubDate>Wed, 21 Sep 2011 19:40:27 GMT</pubDate></item><item><title>tobi commented on How SignalR killed RavenMQ</title><description>You don't have to take all opportunities in life, just the best ones. So +1 for killing it.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment13</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment13</guid><pubDate>Wed, 21 Sep 2011 12:28:43 GMT</pubDate></item><item><title>Ayende Rahien commented on How SignalR killed RavenMQ</title><description>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 &amp; 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.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment12</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment12</guid><pubDate>Wed, 21 Sep 2011 10:57:18 GMT</pubDate></item><item><title>Steve Py commented on How SignalR killed RavenMQ</title><description>@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.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment11</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment11</guid><pubDate>Wed, 21 Sep 2011 10:44:14 GMT</pubDate></item><item><title>Ayende Rahien commented on How SignalR killed RavenMQ</title><description>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</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment10</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment10</guid><pubDate>Wed, 21 Sep 2011 06:11:26 GMT</pubDate></item><item><title>fschwiet commented on How SignalR killed RavenMQ</title><description>Steve, Ayende already has some checkins to a fork of SignalR.  While you find clever ways to question his values, he is writing software.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment9</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment9</guid><pubDate>Wed, 21 Sep 2011 05:30:21 GMT</pubDate></item><item><title>Mike commented on How SignalR killed RavenMQ</title><description>@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? :)</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment8</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment8</guid><pubDate>Wed, 21 Sep 2011 04:38:26 GMT</pubDate></item><item><title>Steve Py commented on How SignalR killed RavenMQ</title><description>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 $.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment7</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment7</guid><pubDate>Tue, 20 Sep 2011 22:21:07 GMT</pubDate></item><item><title>David Fowler commented on How SignalR killed RavenMQ</title><description>@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.</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment6</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment6</guid><pubDate>Tue, 20 Sep 2011 19:48:17 GMT</pubDate></item><item><title>Torkel commented on How SignalR killed RavenMQ</title><description>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. </description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment5</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment5</guid><pubDate>Tue, 20 Sep 2011 19:29:05 GMT</pubDate></item><item><title>Nick commented on How SignalR killed RavenMQ</title><description>+1 for what Marcus Swope said</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment4</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment4</guid><pubDate>Tue, 20 Sep 2011 18:36:21 GMT</pubDate></item><item><title>Lance commented on How SignalR killed RavenMQ</title><description>Are you planning to write your own SignalR.ScaleOut with RavenDB instead of the sql server implementation that is currently in the SignalR project?</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment3</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment3</guid><pubDate>Tue, 20 Sep 2011 16:32:24 GMT</pubDate></item><item><title>Marcus Swope commented on How SignalR killed RavenMQ</title><description>Why not open source it and let the community decide its fate?</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment2</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment2</guid><pubDate>Tue, 20 Sep 2011 13:20:37 GMT</pubDate></item><item><title>zvolkov commented on How SignalR killed RavenMQ</title><description>Can you elaborate on "the sort of things"?</description><link>http://ayende.com/95233/how-signalr-killed-ravenmq#comment1</link><guid>http://ayende.com/95233/how-signalr-killed-ravenmq#comment1</guid><pubDate>Tue, 20 Sep 2011 12:54:08 GMT</pubDate></item></channel></rss>