Multiple Rabbit Virtual Hosts for One Saga

[Todd Meinershagen]

I am trying to use the state-based sagas with MassTransit and RabbitMQ in one of our projects.  This saga currently subscribes/publishes to the default virtual host for the RabbitMQ server, but when we move to production, we want to subscribe/publish to queues on multiple virtual hosts.  

Is it possible when configuring the bus to ReceiveFrom() multiple locations, or should I have multiple service buses with the same SagaRepository being registered?  Or is there another way that I am not mentioning?  Thanks for your help in advance.

[Dru Sellers]

you can only receive from one queue.

so its possible you would want to run multiple service busses.

On Sun, Jul 7, 2013 at 9:21 AM, Todd Meinershagen <to...@meinershagen.net> wrote:

I am trying to use the state-based sagas with MassTransit and RabbitMQ in one of our projects.  This saga currently subscribes/publishes to the default virtual host for the RabbitMQ server, but when we move to production, we want to subscribe/publish to queues on multiple virtual hosts.  

Is it possible when configuring the bus to ReceiveFrom() multiple locations, or should I have multiple service buses with the same SagaRepository being registered?  Or is there another way that I am not mentioning?  Thanks for your help in advance.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/d4b28132-6893-45d9-a20a-38ca09422330%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[sandeepc...@gmail.com]

Not sure if this is relevant or not but I can run multiple copies of same app(using Sagas) on same machine that subscribe to same queue.

Cheers

Sandeep

[Todd Meinershagen]

Thanks, Dru, for your response.  I am actually only subscribing to one queue on one vhost (/estimation), but my state-based saga must receive from exchanges on other vhosts (/pricing).  Is there a way to define the state-based saga to receive from exchanges on different vhosts, but still have the same queue.  (There are multiple entry points for my saga - initially and then in response to calls out to pricing).  I hope this makes sense.

[Chris Patterson]

That's not possible, unless you listen to both virtual hosts (with service bus instances in the same process perhaps). But it will subscribe to all of the saga events on both virtual hosts. If you need to just move messages from one vhost to another, you can set that up using (i believe) federation or shovel (both RabbitMQ configuration things).

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/6aa5b280-51db-4979-a80e-67577cccef7a%40googlegroups.com.

[Chris Patterson]

You can have multiple services reading from the same queue as long as you are doing it to load balance all traffic in that queue across services. Any messages directed to a specific service (such as responses, or other service-level events) should be on a separate queue that is unique to each service bus instance.

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/04011117-3918-41e0-9bf2-5b22a5a7d490%40googlegroups.com.