Re: Get by CORRELID VS Generic Get

[John Scott]

Title: Message

Using expiry report options wouldn't work quite as I would like.   Front end sends request, with own reply queue and own QMgr name.   Backend system processes and sends reply.  To specify report options, backend system must know what front end queue to specify and also what front-end QMgr to specify.  It knows the front-end QMgr 'cos its in the request MQMD which it is already using.  The queue name itself might be different for different front end systems:   WEB.REPLY.QUEUE and WEB.CLEANUP.QUEUE CALL.CENTRE.REPLY.QUEUE and CALL.CENTRE.HOUSE.KEEPING.QUEUE ANOTHER.REPLY.QUEUE and ANOTHER.HOSPITAL.QUEUE MOWBLIE.SMS.REPLY.QUEUE and no other queue 'cos it isn't doing a matched get so they'll all get picked up. etc. etc.   Making the backend system dependent on knowing front end queue names/architecture is too much coupling for me.   In any case, my "requirement" was a theoretical use case.  My requirements would be to be able to get messages that have missed their response thread.   The best one I saw for this was for every response thread that timed out, put the MQMD onto a cleanup/housekeeping/hospital queue and have the cleanup thread use that to get specific messages from the reply queue (a bit like a dead letter handler I guess).  Once the cleanup thread has found a matching reply queue message for the correlid on the cleanup/whatever queue, it can remove the message from both queues and process it.   The backend system does not have to know about any of the front-end system's queue names/architecture, except those passed in the MQMD for normal request/reply.  The cleanup process is a front-end problem, not a backend problem.   I could use application fields/RFH2 headers in the request message for extra queue names etc. but that still makes the backend system depend upon the processing requirements of the front end above the "standard" request/reply scenario.   Regards   John Scott IBM Certified Specialist - MQSeries ARG Infrastructure Services - Middleware   -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Sent: 13 February 2006 13:38 To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT Subject: Re: Get by CORRELID VS Generic Get To solve the problem below, you may consider using the report full on expire, and pass correlid  in the MQMD  in the (web) reply message.  The reply message must also set an expiry time and specify a reply to queue (the queue where you want the expired message to go).    The program that sends emails would listen to the (expiry) reply to queue.   You would need to make sure the web reply queue is somewhat active to ensure the messages "expire"  in a reasonable time, or you could write another program that would browse the messages on the web reply queue to expire them.   It's a little different way of thinking, but it get around all the timiing issues, and which process will pick up the message.   It may require a bit more thinking to make it work well.   regards   Bill W.   —-------------------------------------------------------------------   Paul,   I think you've understood what we've been talking about and I understand your issues.  I'll try and couch it in requirements (as I understand it):   We (I) want to be able to have an application attempt to retrieve a message with a specific match option (e.g. correlid), but with a time out.  If the timeout occurs, we want another thread to be able to pickup the messages that have arrived after a timeout has occurred (and thus will never get picked up).  We don't want the "cleanup" thread to snatch a super-quick response before the main thread has had a change to retrieve the matched response.   As a use-case-scenario:   1. Web site sends customer order placement message to backend fulfilment systems. 2. Web site thread waits for 30 seconds for a response. 3. If response received, web site tells customer order placed and provides order number confirmation etc. 4. If response times out web site tells customer order accepted and details will be emailed later.   A. "Clean up" thread running in parallel to the above picks up late responses from fulfilment system and emails customer.   If the response comes back before the web site gets to step 2 above, we don't want the clean-up thread picking up a response that step 2 would match against.   Regards John. -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] Sent: Friday, February 10, 2006 9:58 AM To: MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT Subject: Re: Get by CORRELID VS Generic Get   My apologies but I've only been keeping one eye on this thread and don't fully understand the issues. My understanding is that you have two applications getting from the same queue, one specifying a messageid and the other willing to accept any message and you wish to ensure that all messages matching the messageid go to the specifc getter. Is this the case or have I missed the point ?   What I don't understand is how you would expect MQ to achieve this ? If Application A isn't doing it's MQGET at the time the message arrives but another application has an outstanding get for it then MQ has little choice but to give it to whichever matches doesn't it ? Or are you suggesting that we hang around for a bit in the hope that the other MQGET comes back ? This would seem fraught with hazard to me; how long would you like us to wait for example.   What is the actual problem you're trying to solve ?; I can't help thinking we're trying to fix a problem in the chosen solution rather than the original requirement,   Cheers, Paul.   Paul G Clarke WebSphere Messaging Clients IBM Hursley   MQSeries List <MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT> wrote on 09/02/2006 21:20:33:   > Hi John, > > Reading the passage again, I agree. I missed the word *attempts* initially. > > That is of concern. Perhaps we should look to raise a requirement to > tighten up MQ capabilities in this area. > > Regards, > >   >  Neil Casey   > > __________________________________________________________________________________   >   >  Senior Systems Programmer > Phone :  +61 3 9886 2375 (x82375) >   >  Middleware Services MQ Support > Mobile:  +61 414 615 334 >   >  Cross Platform & Transaction Services > Fax :  +61 3 9886 2700 (x32700) >   >  Technology Operations > Email : > > [EMAIL PROTECTED] >   >  National Australia Bank   >   >              John Scott   >              <[EMAIL PROTECTED]   >              .CO.UK> To >              Sent by: MQSeries         MQSERIES@LISTSERV.MEDUNIWIEN.AC.AT   >              List cc >              <[EMAIL PROTECTED]   >              V.MEDUNIWIEN.AC.A Subject >              T>                        Re: Get by CORRELID  VS Generic Get >   >   >              02/09/2006 06:22   >              PM   >   >   >              Please respond to   >                MQSeries List   >              <[EMAIL PROTECTED]   >              V.MEDUNIWIEN.AC.A   >                     T>   >   >   > > > > > Hi Neil, > > I don't agree with you for a couple of reasons.  The APG states that > the qmgr only *attempts* to give priority to MQGETs with the more > specific match options.  That's no guarantee. > > I once expected it to work the way you say, but I am sure I have tried this > in the past (AppA sends request, AppB provides response after a > multi-second delay, AppC sat waiting on generic get - AppC sopmetimes > snatches the message).  I would want to check this again just to be > sure. > > Even if my repeated testing observed what you say you expect to > happen, I still don't like IBM's phrase involving "attempts"... > > There's also the fact that I would be concerned what I could put > inplace to > ensure that AppB doesn't deliver a response quicker than AppA can get > to its MQGET call. (Lets say AppA gets swapped out because some other process > is hogging the system for 10 seconds - extreme, put possible). > > Regards > John. > > > > Instructions for managing your mailing list subscription are provided > in the Listserv General Users Guide available at http://www.lsoft.com > Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html   - --------------------------------------------------------------   Check our latest prices and full range at http://www.argos.co.uk   The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited.   The views expressed may not be official policy, but the personal views of the originator.   If you have received this message in error, please advise the sender by using the reply facility in your e-mail software.   All messages sent and received by Argos Ltd are monitored for viruses, high-risk file extensions, and inappropriate content.   Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html - -------------------------------------------------------------- Check our latest prices and full range at http://www.argos.co.uk The information contained in this message or any of its attachments may be privileged and/or confidential, and is intended exclusively for the addressee. Unauthorised disclosure, copying or distribution of the contents is strictly prohibited. The views expressed may not be official policy, but the personal views of the originator. If you have received this message in error, please advise the sender by using the reply facility in your e-mail software. All messages sent and received by Argos Ltd are monitored for viruses, high-risk file extensions, and inappropriate content. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html