Re: Continuous forwarding of priority queue to a non-priority queue
Hello T.Rob, Thank you and Rick for the insights on triggering. My plan was to trigger on MQTT_FIRST and then serve the queue continuously in a loop. If the downstream queue becomes full (let us say, its MAXDEPTH is 10 messages), then my application would wait for it to have, say, 5 free slots and then continue forwarding. While it would wait, arriving messages would be piling on the first QUEUE in the order according to their priority, so that they would go to the FIFO queue in this order, too). Would this work as I think it should (i.e., obey the priority, except for maybe last 10 messages) or am I missing something here? My understanding is that, even if my application were working from PRIORITY queue, and the processing were really fast, the messages would have been processed in a FIFO order, not according to the priority (say, if the CURDEPTH of the queue is always 1 or 0). As I said in the previous e-mail, the reason for using triggering would be to avoid the administration hassle for my own continuously running application (a daemon). After reading the doc, I got a doubt on how reliable triggering really is. If, for some reason, the triggered application crashes without calling MQCLOSE (for the sake of example, let us say it is killed with kill -9, on Unix), and the message arrives to the application queue before the crash but after the last issued MQGET, would the trigger message be sent and the triggered application re-started or the message will stuck until the next message arrives? Thank you, Pavel "Wyatt, T.rob" <[EMAIL PROTECTED]To: [EMAIL PROTECTED] MERICA.COM> cc: Sent by: MQSeries Subject: Re: Continuous forwarding of priority queue to a non-priority queue List <[EMAIL PROTECTED] C.AT> 08/06/2004 10:19 AM Please respond to MQSeries List Pavel, If I understand you correctly, you would deliver the messages first to a queue with MSGDLVSQ(PRIORITY) which triggers a job to them move the messages to a FIFO queue. The only problem I can see with that is that, unless the triggered job is r e a l s l o w, or unless you trigger on depth, the messages still arrive in the FIFO queue in the same order they arrived on the PRIORITY queue. This is because the QMgr can't sort the messages by priority unless they are allowed to first build in the queue. You didn't mention whether your app would trigger on depth or not so maybe you considered this already. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, August 05, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Continuous forwarding of priority queue to a non-priority queue Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List
Re: Continuous forwarding of priority queue to a non-priority queue
Pavel, If I understand you correctly, you would deliver the messages first to a queue with MSGDLVSQ(PRIORITY) which triggers a job to them move the messages to a FIFO queue. The only problem I can see with that is that, unless the triggered job is r e a l s l o w, or unless you trigger on depth, the messages still arrive in the FIFO queue in the same order they arrived on the PRIORITY queue. This is because the QMgr can't sort the messages by priority unless they are allowed to first build in the queue. You didn't mention whether your app would trigger on depth or not so maybe you considered this already. -- T.Rob -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Pavel Tolkachev Sent: Thursday, August 05, 2004 12:16 PM To: [EMAIL PROTECTED] Subject: Continuous forwarding of priority queue to a non-priority queue Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000142&loc=en_US&cs=utf-8&lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley "Capodicci, Dan (GE Commercial Finance)" To <[EMAIL PROTECTED] [EMAIL PROTECTED] .COM> cc Sent by: MQSeries List Subject <[EMAIL PROTECTED] downloading MO71 support pac N.AC.AT> 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to "accept", then I get a "Not Authorized" page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan 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 -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the mater
Re: Continuous forwarding of priority queue to a non-priority queue
Pavel, I'm not entirely sure I understand this priority vs. FIFO delivery dilemma, so I'll just skip to the questions. 1. If you choose to trigger the forwarding application, it certainly is a reasonable choice. 2. But, given the second question, the restriction of forwarding messages due to a "queue full" condition sort of works against the way a triggered application works. The triggered application is responsible for draining the messages and, if it fails to do so, you may run the risk of falling into a trigger loop. Your application could test the QDEPTH of the second queue and decide if there's room to forward some messages. But, in this circumstance, I would think a standalone application that polled the first queue would make more sense. Pavel Tolkachev To Sent by: MQSeries [EMAIL PROTECTED] List cc <[EMAIL PROTECTED] n.AC.AT> Subject Continuous forwarding of priority queue to a non-priority queue 08/05/2004 12:16 PM Please respond to MQSeries List <[EMAIL PROTECTED] n.AC.AT> Hello all, One of my clients has a requirement to my application, which by its design and specification cannot properly process the queue where prioritized messages can be put, to process messages in accordance with their priorities. I figured out that the most rational way to meet it would be to just let MQ to prioritize the messages in some queue with MSGDLVSQ(PRIORITY) and transactionally forward all messages to an additional queue with MSGDLVSQ(FIFO) from where my application could then work. For performance reasons I think it is probably better for this new forwarding application to be server application. For the administration convenience and robustness, I think it might better be a triggered process rather than a standalone daemon. I need help with two questions: 1. Does my solution outlined above make sense? Especially -- what are pros and contras and gotchas for making it a triggered process (I have never written one before)? 2. Isn't there something around ready, like a service pack for doing this type of work? One requirement I feel I will have to consider is that the second queue must not be deep, otherwise, if the downstream process takes too long, the messages of different original priority will pile up in the secondary queue and the client will not be sastisfied with how we actually obey that original priority. So, the solution must properly process the "destination queue is full" condition. Thank you, Pavel Paul Clarke <[EMAIL PROTECTED]To: [EMAIL PROTECTED] IBM.COM> cc: Sent by: MQSeriesSubject: Re: downloading MO71 support pac List <[EMAIL PROTECTED] n.AC.AT> 07/22/2004 09:29 AM Please respond to MQSeries List Dan, Is it possible you're using the old webpage. The SupportPacs have been re-arranged recently. I've just tried it from http://www-1.ibm.com/support/docview.wss?rs=203&uid=swg24000142&loc=en_US&cs=utf-8&lang=en and it seems to work fine for me. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley "Capodicci, Dan (GE Commercial Finance)" To <[EMAIL PROTECTED] [EMAIL PROTECTED] .COM> cc Sent by: MQSeries List Subject <[EMAIL PROTECTED] downloading MO71 support pac N.AC.AT> 20/07/2004 15:00 Please respond to MQSeries List Hi After having read so many positive things recently about the MO71 support pac, I decided to download it and take a look. But of course, it is never that easy :) As I am trying to download it by clicking on the link, I get the license acceptance window which I respond to "accept", then I get a "Not Authorized" page ?!?!?!?!?!??!?!? I have only done this about a million times over the years (although it has been a while since the last) and never had this happen. Has something changed that I missed?!? Any clues about what I can do to download this support pac?!?!? Thanks Dan Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: htt