[rabbitmq-discuss] Many clients using .NET API

[Tony Garnock-Jones]

Hi Sam,

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.

Regards,
   Tony

* depending on heartbeat settings