Hi Sumit,The configuration you propose is supported, as you are simply streaming from Q1 to RQ1 on QMGR1.The rules you highlight would mean that you shouldn't also set up streaming on Q1 on QMGR2 as that would create a chain of connected streams. And the second one prevents you from enabling a stream queue on QMGR1's xmitq instead of Q1 itself.We'll see if we can improve our documentation to make this clearer.So if you are simply looking to duplicate the messages flowing through Q1@QMGR1 so that they also arrive at Q1@QMGR2 then you definitely can.Depending on your needs, you could see this as an HA or DR mechanism, but it is very different to how MQ natively handles HA and DR. The main difference from an application's point of view is that only the production of the messages is being replicated with streaming queues, not the consumption of those messages, unlike something like RDQM which replicates all state changes, keeping multiple representations of the same queue in step.So with streaming queues you'd need your own mechanism in place to be consuming messages from Q1@QMGR2 to ensure that the queue did not over fill, yet still holds enough messages to provide you benefit in the case of a fail over from QMGR1. This would obviously expose you to possibly processing the same message multiple times in the event of a switch from QMGR1 to QMGR2, but maybe you already have ideas on how to handle that within the application.Thanks,David
Thanks David. "The rules you highlight would mean that you shouldn't also set up streaming on Q1 on QMGR2 as that would create a chain of connected streams. And the second one prevents you from enabling a stream queue on QMGR1's xmitq instead of Q1 itself."I understand, technically i can but i shouldn't create a chain of connected streams & neither its supported.can i ask one more question : any specifc reason for launching this feature when i could achieve the same thing ( replicating messages )with MQ pub-sub.Thanks,
Hi Sumit,Just to clarify, your topology is definitely supported.
App -> Q1 (QMGR1)-----RQ1(StreamQ & RemoteQ ) ------xmitQ -------------------------------------Q1(QMGR2)This is because you're simply streaming from Q1 to RQ1. The downstream xmitq and target queue are not a problem, MQ handles all that. We're fixing the documentation to make that clearer.Pub/sub is another way of getting similar behaviour, however it has a couple of aspects that can cause problems for some scenarios:1. It often requires you to make more extensive configuration changes which are exposed out to the application, which isn't always simple to achieve. For example you may need to delete the original queue and replace it with an alias to a topic, or reconfigure the consumer to consume the messages from a different queue.2. The meta data of a message changes when using pub/sub instead of a queue. For example the message IDs will change between the producer and the consumer. This can cause problems with the original applicationThe streaming queue feature is designed so that it doesn't change anything for the original producing and consuming applications on the original queue, so that you can enable this in the knowledge that they'll continue to run exactly as they did before.
Thanks Neil for the detail explanation. :) Thanks,