[rabbitmq-discuss] Many clients using .NET API
tonyg at lshift.net
Tue Jun 30 08:45:00 BST 2009
Sam Owen wrote:
> I’ve just started to look at RabbitMQ. I’m wondering whether the
> following would be an idiomatic use of RabbitMQ from the .NET API:
> Routing.Listen("queue1", "#", new ConsoleAlert());
> Routing.Listen("queue1", "news.#", new EmailAlert());
> Routing.Listen("queue2", "email.#", new ConsoleAlert());
Are you suggesting a layer atop IModel?
> Each call to Listen sets up a thread where the connection and channel
> are maintained.
That makes sense -- especially if it could abstract away the three
options for multiplexing channels over connections that Matthias
Karlsson mentioned in
<83eb635f0906250159u1c700aa6r94f0e124119393a0 at mail.gmail.com>.
Ah, I see by your implementation that you *are* suggesting a layer atop
IModel! It looks, at a glance, plausible, but I'm afraid I'm not the man
to at-a-glance evaluate the code more closely than that :-)
> Given that .NET processes are more heavy weight than erlang’s is this
> the preferred way to set up many clients?
Hmm. Well, in Java there's a thread or so* per connection too, so it's
not an awful way of doing it. On the other hand, if your error-handling
model supports it, you could share a single channel between multiple
subscriptions. It all depends (complexly) on the message rate, the
consequences of a dropped connection, and the level of parallelism you
want in your application.
* depending on heartbeat settings
More information about the rabbitmq-discuss