[rabbitmq-discuss] Many clients using .NET API

[Sam Owen]

Hi Tony,

Thanks for the feedback. Yes I'm looking to find a simple way to scale
publishers and subscribers to topics. We're only looking at a few dozen
of these which would be less than 100 threads in the worst case - the
CLR should be able to cope with. What's nice about this approach is that
we could scale to more processes or boxes if required. 

At the moment we're using non-durable topics only and the approach seems
to work fine. "Routing" has the following methods:

****
//IListener is a call back that receives the message, routing and
exchange the message was sent on
public static void Listen(Destination from, IListener alert) {...

//IFeed should not return until interrupted. It receives a blocking
queue to write messages to as needed
public static void Publish(Destination to, IFeed action) { ...

//The IEvent will be called according to the Quartz trigger. It is given
a blocking queue to write to.
public static void Schedule(Destination to, string jobName, Trigger
trigger, IEvent @event) { ...

//Listens to 'from', filters/transforms and publishes to 'to'.
public static void ListenTransformAndPublish(Destination from,
TransformingFeed feed, Destination to) { ...

//interrupts all threads
public static void Shutdown() { ...
****

Cheers, 
-- Sam

-----Original Message-----
From: Tony Garnock-Jones [mailto:tonyg at lshift.net] 
Sent: 30 June 2009 08:45
To: Sam Owen
Cc: rabbitmq-discuss at lists.rabbitmq.com
Subject: Re: [rabbitmq-discuss] Many clients using .NET API

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



The information transmitted is the property of Gazprom Marketing & Trading Ltd and is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Statements and opinions expressed in this e-mail may not represent those of the company. Any review, retransmission, dissemination and other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender immediately and delete the material from any computer. 

Registered office: Gazprom Marketing & Trading Ltd, Gazprom House, 60 Marina Place, Hampton Wick, Kingston upon Thames, KT1 4BH. Registered in England No. 3768267