Hello Group, yes, messages will sit in the SYSTEM.CLUSTER.TRANSMIT.QUEUE.
There is no different behavior with message persistence. If messages are non persistence, they will be purged during queuemanager restart, no matter wheter they are in a qlocal, xmitq or cluster-xmitq. But you should be aware of the cluster-rerouting mechanism: If there are messages on the SYSTEM.CLUSTER.TRANSMIT.QUEUE and they are not indoubt, then - at every retry interval of the channel - the messages are "get" and "put" again by the cluster rerouting mechanism. This is done because the assigned destination may be not available (thats why its in retry), and the put will select an alternate available destination queue if there is one. This is done with syncpoint control, so it will use a lot of logging depending on the amout of messages and your cluster channel retry interval. We once filled up many cartridges with archive logs (during some days / weeks) because a testsystem was not available for a long period of time and there where some thousands of messages in the SYSTEM.CLUSTER.TRANSMIT.QUEUE..... I do not know if this rerouting mechanism is included in all MQ versions that support clustering, at least its in 5.2 on OS/390. Regards Stefan -----Ursprungliche Nachricht----- Von: Stefan Sievert [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 17. September 2002 01:03 An: [EMAIL PROTECTED] Betreff: Re: Remote Queue Def in a Cluster I would assume that the message will remain on the cluster transmission queue until QM1 is back up running. There might be a difference in behavior depending on whether the log messages are persistent or not, but I'll leave that for somebody who has more real life experience with clustering than I have. Stefan >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: Remote Queue Def in a Cluster >Date: Mon, 16 Sep 2002 17:34:09 -0400 > >You are correct Stefan. (long day) > >I will need a XMIT queue, a remote queue def and a Channel between QM2 and >QM3, just like between QM1 and QM3. > >Next question that I need verification on is as follows: > >Lets say I create a clustered local queue on QM1 called LOGQUEUE. For the >sake of discussion, we are only concerned with putting to this queue. We >want to insure that messages get there, because once a week we run a batch >job to look at that queue. > >When QM1 and QM2 are both up, an app on QM2 can put to LOGQUEUE and the >messages will end up on the local instance of LOGQUEUE on QM1, because >LOGQUEUE is advertised to the cluster. > >IF QM1 goes down, an app on QM2 that puts to LOGQUEUE will have what >happen? >I assume the put will fail, right? And if so, I really should create a >LOGQUEUE on both QM1 and QM2. > >Peter Potkay >IBM MQSeries Certified Specialist, Developer >[EMAIL PROTECTED] >X 77906 > > >-----Original Message----- >From: Stefan Sievert [mailto:[EMAIL PROTECTED]] >Sent: Monday, September 16, 2002 4:58 PM >To: [EMAIL PROTECTED] >Subject: Re: Remote Queue Def in a Cluster > > >Peter, >this sounds more like a channel question than a QR def question. If you >only >have a channel from QM1 to QM3 and QM1 goes down, messages can't travel to >QM3 unless you also have a channel from QM2 to QM3. Correct or am I missing >the point? >Cheers, >Stefan > > > >From: "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> > >Reply-To: MQSeries List <[EMAIL PROTECTED]> > >To: [EMAIL PROTECTED] > >Subject: Remote Queue Def in a Cluster > >Date: Mon, 16 Sep 2002 16:20:35 -0400 > > > >Maybe an obvious question... > > > >QM1 and QM2 are both full repositories of ClusterA. > >QM3 is not part of the cluster. > > > >QM1 has a remote queue def to QueueC on QM3. The remote queue def is a > >clustered queue in ClusterA. > > > >An app on either QM1 or QM2 can now put to QueueC. > > > >What if QM1 goes down? Is the app on QM2 now not able to get a message to > >QueueC? Do I need to make the remote queue def on both QM1 and QM2? > > > > > > > >Peter Potkay > >IBM MQSeries Certified Specialist, Developer > >[EMAIL PROTECTED] > >X 77906 > > > > > > > >This communication, including attachments, is for the exclusive use of > >addressee and may contain proprietary, confidential or privileged > >information. If you are not the intended recipient, any use, copying, > >disclosure, dissemination or distribution is strictly prohibited. If > >you are not the intended recipient, please notify the sender > >immediately by return email and delete this communication and destroy all > >copies. > > > >Instructions for managing your mailing list subscription are provided in > >the Listserv General Users Guide available at http://www.lsoft.com > >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > > > >_________________________________________________________________ >Send and receive Hotmail on your mobile device: http://mobile.msn.com > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive > > >This communication, including attachments, is for the exclusive use of >addressee and may contain proprietary, confidential or privileged >information. If you are not the intended recipient, any use, copying, >disclosure, dissemination or distribution is strictly prohibited. If >you are not the intended recipient, please notify the sender >immediately by return email and delete this communication and destroy all >copies. > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
