| Author |
Message
|
| DarXide |
 Posted: Sun Mar 07, 2010 7:47 am Post subject: paused channel |
 |
|
Apprentice
Joined: 02 Dec 2007
Posts: 43
Location: israel
|
hii im not new in MQ but i run in to an obstacle
i have two qmgrs
QM1 , QM2
QM1 send to two queues on QM2
on QM1 two remote queues 1 XMIT queue 1 channel sender
on QM2 1 reciver channel and 2 local queues
if one of the local queue become full chanel change its status to paused and the sending is becoming really really slow msges go to DLQ etc
and it delay the msgs to another queue
my question is is there something i can do to stop the delay to other queue that empty without creating another XMIT queue and channel or changing the retry of the channel ? maybe priority ? some other way ?
thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Sun Mar 07, 2010 8:09 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DarXide wrote: |
| my question is is there something i can do to stop the delay to other queue that empty without creating another XMIT queue and channel or changing the retry of the channel ? maybe priority ? some other way ? |
Not much. Once you've got a batch of messages that are addressed to a target queue that is full, the receiver MCA has to go through the try putting them to the queue -> find that the queue is full -> send them to DLQ cycle before it can start the next batch. Even if the next batch contains higher priority messages.
So if you know (or have discovered) that messages sit for a while then the local queue should have enough depth to hold the backlog. The real question here is why this local queue is filling? Is the reading application too slow to keep up with inbound messages, or is it prone to crashing/hanging? Do you need more instances of the application, or better monitoring?
So increase maxdepth and find out what's happening with the application. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Sun Mar 07, 2010 8:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Also ensure your DLQ has enough depth & you have an efficient method of reprocessing messages. If the target queue and the DLQ hit maxdepth the channel won't just pause.....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| DarXide |
| Posted: Sun Mar 07, 2010 8:20 am Post subject: thx |
|
|
Apprentice
Joined: 02 Dec 2007
Posts: 43
Location: israel
|
yeah i know the about the bach
i thought i missing something 
and i definitely need better monitoring ! 
is was application crash
tnx guys
and have a nice day |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Mar 07, 2010 9:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The channel is behaving correctly, and as described in the WMQ Intercommunications manual.
A channel in PAUSED state means that it is waiting for message-retry interval to expire. Retry intervals are the channels way of attempting to recover from a problem.
The problem here is that the channel could not successfully deliver persistent messages to a destination queue (queue put-inhibited, queue full, msg too big for the queue, other reasons), AND could not deliver the messages to the dead-letter queue (same reasons).
Once short- and long-retry intervals expire, the channel would go into STOPPED state.
PAUSED and retries allows for self-correction. For example, the consuming application starts, or consumes enough messages that frees up space in the queue, or the dead-letter handler processes the messages out of the dead-letter queue. Any of these will allow the channel can continue sending/receiving messages.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Mar 07, 2010 12:53 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If you need to, read the manual for the right references. AFAIK there is way to reduce the retry wait interval and the number of retries before the channel agent attempts to put the message to the DLQ.
The best medicine however is to make the target qdepth sufficient and to monitor that queue for depth and enqueue/dequeue rate in order to catch any problems early and fix them before they become critical...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Mar 07, 2010 1:02 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
fjb_saper is referring to the channel message retry exit program.
I don't know if you would find it useful for application failure situation such as the one in the OP. Retries would seem to be more appropriate for brief server or application slowdowns.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Mar 07, 2010 10:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| bruce2359 wrote: |
fjb_saper is referring to the channel message retry exit program.
I don't know if you would find it useful for application failure situation such as the one in the OP. Retries would seem to be more appropriate for brief server or application slowdowns. |
I was referring specifically to the MRRTY and MRTMR attributes of receiver/requester/cluster receiver channels.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.csqzaj.doc/sc10510_.htm
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| DarXide |
| Posted: Sun Mar 07, 2010 10:23 pm Post subject: |
|
|
Apprentice
Joined: 02 Dec 2007
Posts: 43
Location: israel
|
guys guys
relax
i said that i dont want to change anything in the queues or in the channel
thanks alot ! |
|
| Back to top |
|
|
|
|
