| Author |
Message
|
| gag_nm |
 Posted: Fri Feb 26, 2016 12:46 am Post subject: Queue depth increasing at Transmission Queue |
 |
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
Dears,
We have 2 Queue Mnagers QMA and QMB.
We have created below queues on each Queue Manager.
QMA-
1.Local Queue to receive response.(QMA_LCL)
2.Trasmission queue(TMQB)
3.Remote queue(QMA_RMT)
QMB-
1.Local queue receive Request From QMA.(QMB_LCL)
2. Trasmission queue(TMQA)
3.Remote Queue(QMB_RMT)
When are trying to send messages from QMA to QMB.at times message reaches destination with out any issue ,but some instance Messages are piled up on TMQB Transmission Queue and after some minutes all messages are sent destination queue. We thought issue is with channels at that instant ,we verified channels were up and running ,ping and telnet were both working.
We are unable to find reason behind messages piled up TMQB. Can some please help us to solve issue. |
|
| Back to top |
|
 |
| MQsysprog |
| Posted: Fri Feb 26, 2016 1:46 am Post subject: |
|
|
Centurion
Joined: 24 Feb 2014
Posts: 116
|
Hello ,
a good clue may be in the network performances when you see a high qdepth on the tx queue .
You can check the network speed with some display chstatus command done on the sender channel ,to see the number of messages sent and their average size ...
Hope it helps |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 26, 2016 4:31 am Post subject: Re: Queue depth increasing at Transmission Queue |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| gag_nm wrote: |
we verified channels were up and running ,ping and telnet were both working.
We are unable to find reason behind messages piled up TMQB. Can some please help us to solve issue. |
"up and running" is not MQ terminology. When you displayed CHSTATUS, was the channel actually in RUNNING state? Or did it go into RETRY briefly?
RUNNING indicates that the channel is either transmitting a batch of messages, OR that it believes that it can do so the next time it tries.
What are the values of BATCHSIZE and BATCHINTERVAL at both ends of the channel?
Did you look at the error logs on both sending- and receiving- qmgrs? Any channel or TCP errors logged?
_________________
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 |
|
|
| gag_nm |
| Posted: Sun Feb 28, 2016 6:29 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
we have tried CHSTATUS command on channel when there were no messages on queue. output as shown below
| Code: |
DISPLAY CHSTATUS (A2.B2)
2 : DISPLAY CHSTATUS (A2.B2)
AMQ8417: Display Channel Status details.
CHANNEL(A2.B2) CHLTYPE(SDR)
CONNAME(XXX.XXX.4.86(1414)) CURRENT
RQMNAME(AXABRX2P) STATUS(RUNNING)
SUBSTATE(MQGET) XMITQ(B2.XMITQ)
|
we have tried CHSTATUS command on channel when there were 11 messages on queue. output as shown below.
| Code: |
DISPLAY CHSTATUS (A2.B2)
2 : DISPLAY CHSTATUS (A2.B2)
AMQ8417: Display Channel Status details.
CHANNEL(A2.B2) CHLTYPE(SDR)
CONNAME(XXX.XXX.4.86(1414)) CURRENT
RQMNAME(AXABRX2P) STATUS(RUNNING)
SUBSTATE(RECEIVE) XMITQ(B2.XMITQ)
|
We found below info on IBM knowledge center
RECEIVE -If the sender is seen in RECEIVE substate for any length of time, it is waiting on a response, either to a batch completion or a heartbeat. You might want to check why a batch takes a long time to complete.
how we can check this ?
Is it something to do with network or with parameters on Mq Channel ??
Below details are configured on Channel.
batch Heart beat interval is 0
batch size is 50 |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Feb 28, 2016 6:51 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Set batch size to 1.
_________________
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 Feb 28, 2016 6:54 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If your channel handles both persistent and non persistent message, make sure you check the channel logs on both sides and that there is no sequence number discrepancy or any other error reported on the channel.
If the XMITQ still has a depth and the messages take longer than usual to pass through the channel, you may also want to check the target queue manager for any queue that is full.
Typically messages sent to a full queue will take some time before being put to the DLQ (or stopping the chl if DLQ not used). This slows down the channel throughput considerably.
You may have to set a greater max queue depth for the queue that is full or (preferably) scale the application consuming those messages.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Feb 28, 2016 7:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
This could simply be uncommitted MQPUTs that contribute to the queue depth but are messages that are not yet available to be gotten by the channel to send.
Check the queue status of the XMITQ the next time this occurs for Uncommited Messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| gag_nm |
| Posted: Wed Mar 23, 2016 1:59 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
Dear ,
we saw UNCOM(1) on below command and Queuedepth to CURDEPTH(10),
what could be possible reason for Un-commited messages. can we make it always committed.
| Code: |
DISPLAY QSTATUS(B2.XMITQ) ALL
3 : DISPLAY QSTATUS(B2.XMITQ) ALL
AMQ8450: Display queue status details.
QUEUE(B2.XMITQ) TYPE(QUEUE)
CURDEPTH(10) IPPROCS(1)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MEDIALOG( ) MONQ(OFF)
MSGAGE( ) OPPROCS(2)
QTIME( , ) UNCOM(1) |
|
|
| Back to top |
|
|
| gag_nm |
| Posted: Wed Mar 23, 2016 2:01 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
| I have Changed BatchSixe to 1 as well. but still messages are on queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 23, 2016 4:11 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| gag_nm wrote: |
| what could be possible reason for Un-commited messages. |
The putting application has not committed the message. That's about the only possible reason.
| gag_nm wrote: |
| can we make it always committed. |
You can change the putting application not to use syncpoint (which might not be a good idea from an application design standpoint) or better still, fix the application so that it always commits every message in good time.
There's nothing you can do administratively to fix this. There's no queue attribute that controls when or if a message is committed. That's under the control of the application.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 23, 2016 4:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| gag_nm wrote: |
| what could be possible reason for Un-commited messages. |
Apart from the very valid reason described by my esteemed colleague, here is another possibility:
The channel is in retrying mode and the channel agent has not yet committed or rolled back the current batch...You really need to check the error logs on both ends of the channel.
This reading would be very transient and subject to the right timing. The not yet committed messages by the putting application is much more likely a reason...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Mar 23, 2016 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| fjb_saper wrote: |
The channel is in retrying mode and the channel agent has not yet committed or rolled back the current batch...You really need to check the error logs on both ends of the channel.
This reading would be very transient and subject to the right timing. |
I discounted this because you should see the status as RETRYING not RUNNING if this is happening often enough to cause the queue to back up. It's even less likely if you've successfully changed the batch size to 1.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 23, 2016 5:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Vitor wrote: |
| fjb_saper wrote: |
The channel is in retrying mode and the channel agent has not yet committed or rolled back the current batch...You really need to check the error logs on both ends of the channel.
This reading would be very transient and subject to the right timing. |
I discounted this because you should see the status as RETRYING not RUNNING if this is happening often enough to cause the queue to back up. It's even less likely if you've successfully changed the batch size to 1. |
It's more likely to happen if you have messages for a full queue on the target qmgr. And I believe in this case you might even see the channel in RUNNING mode... Putting all those messages to the DLQ in the target qmgr and retrying before going to the DLQ takes time...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Mar 23, 2016 9:28 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I agree, one of your application queues filling up could yield this symptom. What is the output of the DIS CHS(*) ALL command when you are in 'slow' mode? Do you ever see the receiver channel go into state PAUSED ? What is the maximum depth of the target queues and is it possible you've reached it ?
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| gag_nm |
| Posted: Fri Mar 25, 2016 2:34 am Post subject: |
|
|
Centurion
Joined: 16 Oct 2008
Posts: 102
|
Application is WMB 8.0.0.3. It is using Mqoutput node to put message on transmission queue.
Application is putting message on Remote Queue to send message to other Queue Manager.
It is some issue using Remote Queues??..
I don't understand how to solve this uncommitted messages. |
|
| Back to top |
|
|
|
|
