Local or remote queues in pub / sub messaging

Question

If I built a system with dozens of publishers / subscribers using message queues, it seems that I have several network configuration options:

• I can have one cluster broker that uses all the machines - each machine will not have a local queue
• I could install brokers locally on each machine and use store-and-forward to deliver messages to remote computers.

Different technologies seem to enforce different configurations - for example, MSMQ requires each machine to have its own local queue, while Tibco EMS is often used in clusters, without local queues for each user.

What are the disadvantages of not having a local queue and what factors influence the decision?

Answer 1

Without a local queue that provides long-term message storage, you cannot guarantee message delivery. Using something like RabbitMQ in a cluster with a broker instance locally gives you a solid mechanism for storing messages for delivery. If you need to connect through a network connection to a remote broker to send a long-term message, you risk a network failure.

MSMQ is also a repository and forwarding, but it does not provide cluster routing capabilities. This means that the application must do the work (or have a layer on it, for example MassTransit or NServiceBus, for this).

When I think of TIBCO, I think of a centralized cluster of EMS servers with which application servers interact, instead of a local broker instance. The GUI tools that span EMS and BusinessWorks application servers really push the model into this world.

In any of the distributed cases where messages are stored locally, it is important to make sure that the computer itself is properly equipped for storing messages, with a fast disk and sufficient disk for the expected message size / capacity.

Answer 2

I would risk that a local queue would be needed in most scenarios.

A local queue is necessary if the message is to be durable. In other words, if the connection to the remote queue is unreliable, and you want the message to reach its subscribers eventually, you need the ability to store and forward the local queue.

If the message should not be long-lived (it may be lost after the event is fired), then a remote shared queue will be an option.

You can look at the NServiceBus distributor model , which will be a hybrid of your two scenarios: a local queue on each machine to go to a remote broker / distributor cluster.

Answer 3

I'm not sure I agree with the comments on MSMQ as they seem deprecated. Maybe I missed something.

Both scenarios are supported in MSMQ.

In Scenario 1, clients will use Transactional Remote Receives (MSMQ 4.0 and above). Being transactional, receiving a reliable and durable message (unlike earlier versions of MSMQ, as interrupted, it receives a message about exit to the server).

In Scenario 2, the outgoing call queue for storage and forwarding will be sent to the local transactional queue on the client (again reliable and durable).

Reliability and durability should not be decision points for using local remote queues. The metric is the difference here for MSMQ.