Design Question - multiple boxes, where to put queues

[dim]

hey all,

this is I suppose a bit of a newbie design question. If I'm to have a situation where I have a number of boxes that do a number of processes, like this:

 |----> X
 A ---|----> Y
 |----> Z

So box A has tasks that need to be (reliably) done by box X, Y, _and_ Z. Which of the following designs would be 'better'?

Option 1:
Have messages sent to three queues on box A, and X, Y, and Z each listen to those queues. This would enable another box X2 to be plugged in, and start listening to queue X to share the load for that process. This seems to be the better approach.

Option 2:
Have a queue on each box X, Y and Z. box A sends messages to each of those queues. I dont really see the advantage of this approach.

So now that I've written this, it seems really obvious - but I'll post it anyway.

thoughts, arguments?

cheesr
dim

[user57]

If every message sent my A needs to be processed by X, Y & Z then a topic would be more appropriate, durable if need be.

If there is a one to one for messages sent from A to X, Y or Z, then either a single queue w/message selector or queue per host will work. It depends alot on your administrative needs and the desired through put. For example if you expect a high through put for processing on the X/Y/Z side, then seperate queues can potentially be faster (depending on the provider impl), because the resource will only be locked for write 1/3 the time (by A) and will only be locked for read by X, Y or Z.

If you plan to have a very dynamic system, where you add/remove Xn/Yn/Zn nodes then it might be easier to handle one destination and use message selectors to filter.

If you abstract the destination configuration then it should be fairly simple to switch between the different schemes with little effect on the design of the application.

--jason

[dim]

Jason,

Thanks for the response.

As you suggest, all messages need to be processed by X, Y and Z, so following your suggestion a durable topic would be more appropriate. To be honest I haven't really dealt with durable topics yet, so will need to do some reading, but... I assume that with a durable topic, I'll need to make sure I get the subscription set up, before any messages start arriving, yes? From the name, I assume that if the connection dies, the client (X) will be able to reconnect, and get any 'missed' messages. Therefore, it will be up to me to ensure that the connection exists before any messages come in.

X,Y and Z are on a different box because they are expected to be slow, and are not time critical, so any performance gain from having multiple queues would probably be eroded pretty quickly.

So in this case, we will have a topic on box A, and have X, Y and Z have durable subscriptions to that topic.

thanks for the help.

cheers
dim

[hchirino]

sounds right