Nonpersistent messages and a NPMSPEED of FAST can result in lost messages.
Greg Mabrito I/T Asct Sys Prgrmr IMS and MQ Software Support (210)913-3985 D-03-E IBM Certified Specialist - Websphere MQ The opinions herein are solely Greg's and are not necessarily the opinion of USAA. -----Original Message----- From: Ruzi R [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 14, 2002 2:11 PM To: [EMAIL PROTECTED] Subject: Re: Lost MQ message (They are fast and nonpersistent) And there were no problems with those "fast" channels when the messages were lost? Ruzi --- "Potkay, Peter M (PLC, IT)" <[EMAIL PROTECTED]> wrote: > Nope it's copied from the request, which set it to 3 > days. > > The log file confirms that the reply is being put > with this large value. > > > Peter Potkay > IBM MQSeries Certified Specialist, Developer > [EMAIL PROTECTED] > X 77906 > > > -----Original Message----- > From: DiLauro, Nick [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 1:25 PM > To: [EMAIL PROTECTED] > Subject: Re: Lost MQ message (They are fast and > nonpersistent) > > > The reply could also be lost anywhere along the > route if the expiry time has > been exhausted. Is this a possibility? > > -----Original Message----- > From: Potkay, Peter M (PLC, IT) > [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 14, 2002 10:02 AM > To: [EMAIL PROTECTED] > Subject: Lost MQ message (They are fast and > nonpersistent) > > > My customer's application is losing an occasional > message and I can't figure > out why. Maybe someone has something else I can look > at. > > VB app client connects to QM1 to put a nonpersistent > request message to a > remote queue pointing to Queue1 on QM2. Put is > outside of syncpoint and the > Expiry is 3 days. > > Message is routed thru our Hub (QMHUB) and lands on > Queue1 on QM2. Queue1 is > triggered on first and starts up a C program running > locally on the Unix > Tru64 box housing QM2. The reply is built and put to > the > ReplytoQueue/ReplytoQueueManager of the Request > message. The Expiry of the > reply is equal to the remaining Expiry of the > request. The request is > nonpersistent and outside of syncpoint. The replying > app has its internal > logging turned on is outputting to a file the MQPUT1 > RC, the reply to info > it used, the expiry, etc. > > 99% of the time everything is OK. But occasionally > the requestor said it > didn't get a reply. The reply queue has no orphaned > reply messages. The log > for the replier says that it did receive the request > and did in fact put out > the reply. But the message is gone. Not on the reply > queue, not on the DLQ > or any XMIT queue on QM1, QM2 or QMHUB. > > Using MO71, I see via Queue statistics that the > replier did get X messages > put onto its request queue, and X messages were > removed from the request > queue. The replier confirms that they put X > requests. The replier's log says > they got X requests, and put X replies. The reply > queue statistics however > say that only X-1 messages were put to the queue and > X-1 messages were > gotten from the queue. > > > Where is this message disappearing to? The only > thing I have left now is the > fact that the channel from QM2 to QMHUB and from > QMHUB to QM1 is defined as > MQNPS_FAST. And the Intercommunications manual says > the following: > > >>>>>>>>>>>>> > If a channel terminates while fast, nonpersistent > messages are in transit, > the messages may be lost and it is up to the > application to arrange for > their recovery if required. Similarly, if the MQPUT > by the receiving MCA > fails for any reason, the messages are lost. > >>>>>>>>>>>>> > > Could my message be getting tossed? How would I know > this is happening? > > > > 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 > > 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 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
