RabbitMQ .Net client that supports async/await operations?

[Michael Watson]

Is there a client for RabbitMQ that that leverages asynchronous support in the .NET Framework 4.5 and the Windows Runtime?  I would like to be able to access RabbitMQ from Microsoft's Project Orleans, to allow Orleans-resident grains to interact with RabbitMQ.  Operations within grains are best done with asynchronous APIs that return Task objects.  

The current official RabbitMQ client does not support .Net 4.5 asynchrony.  Hoping someone knows of one that does...

Cheers -- Michael W.

[Michael Klishin]

As of .NET client 3.5 you can provide a custom task scheduler for consumer operations. Even prior to that, EasyNetQ have been using TPL in their library for a while.

So, it should be pretty straightforward to make your consumers concurrent using any of the approaches available in .NET.

There are no alternative clients, only projects that build on top. RabbitMQ core team accepts feature requests on this list if you care to be more specific what exactly you want to see added :)

MK

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To post to this group, send email to rabbitm...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Klishin]

+rabbitmq-users — please keep the list on CC.

On 8 April 2015 at 06:06:28, Michael Watson (mswa...@gmail.com) wrote:
> It's tempting to use the Parallel Task Library for executing
> parallel tasks in Orleans, but TPL uses the .NET thread pool to
> dispatch tasks. This is prohibited within Orleans 'grain' code
> (grains are the term for the actor objects that run within Orleans
> 'silos').
>
> Orleans has it's own task scheduler which provides a single threaded
> execution model used within grains. This means that objects
> running within the Orleans framework don't have to worry about
> mutexes, etc... But in order to scale, all interactions with
> the world outside the grain must support async/await. The whole
> silo runs with just a small number of threads, yet easily supports
> 100,000 active objects, scaling up linearly by adding new silos
> on new machines.
>
> There is a mechanism for starting subtasks that use Orleans'
> own scheduler. But since Rabbit's client.dll starts its own
> threads using the .Net scheduler, that almost certainly won't
> work.
>
> It's a shame, because Orleans offers a highly scalable actor
> framework with pluggable stream providers that support a number
> of other messaging providers, but RabbitMQ is the one I use. Paired
> with RabbitMQ services that live outside the Orleans framework,
> I believe Orleans could drastically simplify the building of
> apps that scale.

Luckily it's fairly trivial to make it possible to provide your own consumer
dispatcher implementation. In fact, I suspect it's already possible:

https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/master/projects/client/RabbitMQ.Client/src/client/impl/Connection.cs#L105
https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/master/projects/client/RabbitMQ.Client/src/client/impl/ConsumerWorkService.cs

default implementation:
https://github.com/rabbitmq/rabbitmq-dotnet-client/blob/master/projects/client/RabbitMQ.Client/src/client/impl/ConcurrentConsumerDispatcher.cs

Note that this implementation preserves per-channel dispatch ordering. While not a strict requirement,
this is generally a good idea.

Can we somehow support Orleans without requiring .NET 4.5?
--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

On 8 April 2015 at 13:19:11, Michael Klishin (mkli...@pivotal.io) wrote:
> Luckily it's fairly trivial to make it possible to provide your
> own consumer
> dispatcher implementation. In fact, I suspect it's already
> possible:

Spoke too soon: the property setter is private. But now we have a real reason to make it public.

Nonetheless it is fairly easy to make the dispatcher swappable.