| Author |
Message
|
| srikanthc60 |
 Posted: Mon Feb 09, 2015 1:53 am Post subject: sender channel was indoubt and RCVR chl is paused |
 |
|
Voyager
Joined: 21 Jul 2013
Posts: 79
|
My XMITQ has around 49K messages with UNCOM(30) and sender channel is running with INDOUBT(YES) and at receiver side RCVR channel is PAUSED and destination queue was full.
I resolved the channel with ACTION(BACKOUT) and then increased the MAXDEPTH for destination queue , then messages got processed form XMITQ and SDR channael comes to running with INDOUBT(NO) .
Again for the next batch of incoming flow, same issue is repeating, as XMITQ with UNCOM(30) , sender with INDOUBT(YES) and RCVR channel PAUSED and destination getting full again.
Incoming messages are more and outgoing is very slow.
What is happening in this scenario.
What happened when resolved the channel first time, messages are lost or backout for resending .
I would be grateful, any one helps me in understanding this scenario. |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Mon Feb 09, 2015 3:24 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
You should always be very careful with the RESOLVE CHANNEL command and there are very few occasions where it should be necessary. Just because a channel is indoubt DOES NOT mean you have to manually resolve the channel.
If you do decide to use RESOLVE CHANNEL then ACTION(BACKOUT) will potentially duplicate messages whereas ACTION(COMMIT) will potentially lose messages.
If you are getting a queue full condition then it suggests that either your queue depth is too low or that the application processing the messages is too slow. What is the maxdepth of this queue ? You can change the msgretry values on the receiver channel to change the behaviour of the channel when it gets a reason code like Q_FULL.
Unfortunately though MQ does not have the ability to 'push back' right back to the original putter. It is something I often argued for when I was working for MQ Development but it never quite made the cut.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| srikanthc60 |
| Posted: Mon Feb 09, 2015 5:44 am Post subject: |
|
|
Voyager
Joined: 21 Jul 2013
Posts: 79
|
Thanks for the reply.
Maxdepth of xmitq is 50000 and for destination queue is 150K . I have added 250K maxdepth to destination queue and it is getting full within 5mins and the Rcvr channel is going to paused state |
|
| Back to top |
|
|
| srikanthc60 |
| Posted: Mon Feb 09, 2015 5:46 am Post subject: |
|
|
Voyager
Joined: 21 Jul 2013
Posts: 79
|
Where should I actually need to use resolve command
Is it necessary in above case ? |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Feb 09, 2015 5:49 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
So the question remains, what is reading from the destination queue that is getting full, and why is it that it cannot keep up with the number of messages? Can you have more instances of the program reading the queue, so that they can keep up?
The paused state of the RCVR channel simply shows that it is retrying the put to the target queue. If you don't want it to do this, and just go straight to error processing (DLQ the message etc), you can turn off MRRTY.
You'd be better focusing on the reason why the application can't keep up with processing the messages.
| srikanthc60 wrote: |
Where should I actually need to use resolve command
Is it necessary in above case ? |
As Paul said, it is not necessary in your case. It is only required when the receiver queue manager is no longer available - permanently. If there is a temporary blip in connectivity to a remote queue manager, the channel protocol will automatically resolve anything that is required when it starts up.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Last edited by hughson on Mon Feb 09, 2015 5:53 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 09, 2015 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srikanthc60 wrote: |
| Maxdepth of xmitq is 50000 and for destination queue is 150K . I have added 250K maxdepth to destination queue and it is getting full within 5mins |
So why is that? Is there a problem with the receiving application or is it simply that the enqueue rate is that much faster than dequeue? How did you arrive at 250K as the correct depth rather than (for example) 500K?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Feb 09, 2015 5:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| srikanthc60 wrote: |
| Where should I actually need to use resolve command |
When there's been an honest-to-goodness problem with the MCAs and they're out of sync.
| srikanthc60 wrote: |
| Is it necessary in above case ? |
No.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| srikanthc60 |
| Posted: Mon Feb 09, 2015 6:44 am Post subject: |
|
|
Voyager
Joined: 21 Jul 2013
Posts: 79
|
Thanks to all for your replies...
Application team asked me to add maxdepth to the queue
Now I need to question our application folks ,why the messages are processing too slow |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Feb 09, 2015 8:28 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
The default receiver retry setting is 10 times at one second intervals.
This means each message that can't be put (due to a full queue), will take 10 seconds before hitting the DLQ.
All other (persistent) messages will be held up behind these retries (even if they are destined for queues that are not full).
This can cause very long delays in delivery of messages, especially if a lot of messages are being sent (which is of course usually the reason for a full queue!).
It's a MQ feature (or at least a default) that is potentially very unhelpful.
Ideally there would be an option to continue processing the messages destined for other queues in between these retries.
Or, of course, you can turn the retry feature off.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
|
|
