IIB to MQ: Switching JMSInput between queue managers using CCDT

Question

I'd like my Integration Bus flow instance to be able to switch the reading from/writing to multiple queue managers, which are all active at the same time, all having the same queue definitions. Much like having a multi-instance QM, but the QMs in this case would not be related, and I would like to read for instance in sequence from the QMs.

A clean solution would be to use a single JMSInput node per flow, so I'm wandering if that is possible by using CCD tables.

Answer 1

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.

Answer 2

I don't think so. I believe that the choice of channel is made at the time the JMS Connection object is instantiated and broker will cache a single JMS connection per node. It will only ever try to recreate this connection if it experiences an exception that indicates the connection is broken.

So I think using a CCDT you could get some fail over but not the kind of load balancing you are looking for.