Re: Continuous forwarding of priority queue to a non-priority queue

2004-08-06 Thread Pavel Tolkachev
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

2004-08-06 Thread Wyatt, T.rob
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 

Re: Continuous forwarding of priority queue to a non-priority queue

2004-08-06 Thread Rick Tsujimoto
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 fo

Continuous forwarding of priority queue to a non-priority queue

2004-08-06 Thread Pavel Tolkachev
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 material in this e-mail is strictly forbidden.

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