The usual advice for anything that listens on a well-known queue (for example, something servicing the requests in a Request/Reply scenario as is usually the case for Broker flows) is that it does not fail over from queue to queue. There are many reasons for this but the main ones are that this precludes transactional GET
and that it is possible to end up with un-served queues where messages build up and are not processed.
Although it is possible to have a server app do a round-robin as you are describing, the CONNECT
/DISCONNECT
operations are much more expensive than are the GET
/PUT
operations. The result is that a flow that serviced many queues in rotation would perform orders of magnitude more slowly than an Execution Group with multiple flow instances where each is pointed at a different queue instance.
If there is any need to secure those broker connections, the channel will probably use TLS and mutual authentication. That compounds the CONNECT
/DISCONNECT
delay to as much as a second or more per connection attempt. Since the TLS handshake only occurs on the connection and not per-message, this is of little consequence in the normal model of 'one queue per flow'. However, in a round-robin connection scheme you'd be lucky to get 1 message per-second per-queue. This is, of course, true of any TLS connection and not specific to WMQ.