| Author |
Message
|
| bbburson |
 Posted: Wed Dec 15, 2004 1:45 pm Post subject: |
 |
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| JT wrote: |
| If there was a problem with the receiver channel on the remote queue manager, it would have nothing to do with the target queue(s). A "queue full" condition results in the arriving message being re-directed to the dead-letter queue of the remote queue manager, which implies the receiver channel was running. |
There is a side effect of a queue filling up: the sender channel will shut itself down and then periodically start up and send a few messages. If the new messages continue to go to the DLQ this process will repeat and so you'll see the transmit queue on the sending end start to fill up.
The good thing about this is that fewer messages end up on the DLQ. The bad thing is that messages destined for other, non-full, queues on the target system will get caught in the logjam and not be delivered in a timely manner.
Once we observed this behavior a time or two we put strong procedures in place to avoid full queues at almost any cost. Our support group can and does increase the MAXDEPTH on a queue if it starts filling up, along with actively contacting the application that is supposed to read the queue to get them back online. |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Wed Dec 15, 2004 4:54 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
There is a side effect of a queue filling up: the sender channel will shut itself down and then periodically start up and send a few messages.
|
The SNDR channel stays RUNNING. It does not shut down. Yet the XMITQ starts piling up. Can be confusing if you don't go look at the RCVR, which is in a PAUSED state.
The RCVR is in a PAUSED state whenever it encounters what might be a temporary reason for not being able to put a message (Q Full, Q PutInhibited). If it finds a Q like this, it will look to its Message Retry Interval parameter to see how many milliseconds it must wait before trying that message again. It will do this however many times its Message Retry Count attribute specifies. The defaults are 1000 and 10. Meaning a RCVR channel will be PAUSED for (10 x 1 second) for every message it can't put. That can really gum up the works!
Bob, its good for many other reasons to keep your queues from filling up. But if you want this not to bite you in the future, just change the values to 0. The RCVR channel will instantly put the messages to the DLQ and everything will not be held up.
But realize then that your DLQ could very rapidly fill up. And once that is full, and no RCVR MCAs can put to it, the next RCVR MCA that has a problem will STOP the channel HARD, requiring manual intervention to restart it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Nigelg |
| Posted: Wed Dec 15, 2004 10:38 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| The answer to why the channel does not start is in thq qmgr error log. After the AMQ9002, Channel starting, and before the AMQ9999, Channel ended abnormally, will be another error msg describing the reason why the channel did not start. Find that msg, and fix the condition it describes. |
|
| Back to top |
|
|
| anderc1 |
| Posted: Thu Dec 16, 2004 7:35 am Post subject: |
|
|
Acolyte
Joined: 11 Sep 2002
Posts: 55
Location: Research Triangle Park, NC
|
The reason I mentioned the possibility of a full queue on the receiver end is because this bit me recently. Yes, the theory is that when the receiving queue is full the messages should go to the DLQ. In my case they didn't, don't know why. Maybe the MCA tries so many times to put to the destination queue before it sends them to the DLQ? There were no messages in the xmitq on the sender side and the sender channel was in a retry. After stopping the channels at both ends, backed out the messages the MCA was hanging onto which then appeared in the xmitq, reset sequence number, started the receiver started the sender only for it to initially start then go into retry. Backed the message out, deleted & recreated the channels only for the same thing to happen again. Checked queue depth for grins on the receiver, target queue set for 5K messages and it contained 5K messages. Kicked off the app that was supposed to clear the queue and the channel started once the queue began clearing. I ran a test at one time to see what would happen in this exact (queue full) scenario and seems like the sender would pause when it couldn't deliver messages, not go into retry. MQSeries, gotta love it!  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Dec 16, 2004 12:17 pm Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| anderc1, all you had to do was read the error msgs in the qmgr error logs, and it woul;d have told you what was wrong, probably the msg about the qmgr did not accept the last batch of msgs because of reason code 2053, instead of jumping through all those unnecesary hoops. |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Fri Dec 17, 2004 2:00 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
thanks...
We didnt have a DLQ defined... 
Now we do, BUT... this time the channel just puts them in tada... our DLQ... cant put the on the remote q.
and it still doesnt start up if i put a message on my outgoing q.
strange...
we've been workning on this for a week now... and i wont get x-mas until its done...
Petter |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Dec 17, 2004 3:04 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Have you got an amqsbcg dump of the msg in the DLQ? |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Fri Dec 17, 2004 4:06 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
yes... cant make much off it...
MQGET of message number 18
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 546 CodedCharSetId : 1208
Format : 'MQDEAD '
Priority : 0 Persistence : 1
MsgId : X'414D5120494E5456312E514D20202020233FA34105291C20'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'INTV1.QM '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0431313434000000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
** Origin Context
PutApplType : '6'
PutApplName : 'amqsput '
PutDate : '20041216' PutTime : '10015742'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 176 bytes
00000000: 444C 4820 0100 0000 0F01 0000 2020 2020 'DLH ........ '
00000010: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000040: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 2020 2020 2202 0000 ' "...'
00000070: 3303 0000 4D51 5354 5220 2020 0600 0000 '3...MQSTR ....'
00000080: 7275 6E6D 7163 686C 2020 2020 2020 2020 'runmqchl '
00000090: 2020 2020 2020 2020 2020 2020 3230 3034 ' 2004'
000000A0: 3132 3136 3130 3031 3537 3432 4947 454E '121610015742IGEN'
No more messages
...
well....
regards
Petter |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Fri Dec 17, 2004 6:45 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
The strange thing is that the messages gets put on the DLQ the same second they are put on the transmission queue.
regards
Petter |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Dec 17, 2004 7:04 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The DLH shows that the error is 271, which is MQFB_XMIT_Q_MSG_ERROR.
Looking at the msg, this is indeed true, because the msg is not in the correct format to be sent down the channel.
The msg is format MQSTR, when it should be MQXQH.
Are you putting the msg directly to the xmitq? You should be putting the msg to a remote queue, and a load of other stuff. |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Mon Dec 20, 2004 12:58 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
i see... ( i dont understand "where" in the message you found the that but thats great!)
Anyway im putting the textmessage on the transmisson queue, is that the wrong way to go???
My manager etc is set up with this script, and im puttning my messages on the host.intv1.q....
| Code: |
* Creamos la cola remota que apunta a la
* cola de recepción en el Queue Manager de una pasarela de la PAM
def qr (INTV1.Q.TX) +
descr('Cola remota de INTV1') +
defpsist(YES) +
put(ENABLED) +
rqmname(PAM.QM) +
rname(INTV1.Q.RX) +
xmitq(HOST.INTV1.Q)
* Creamos la cola de transmisión
def ql (HOST.INTV1.Q) +
descr('Cola local de Transmision de INTV1') +
defpsist(YES) +
put(ENABLED) +
trigger +
initq(SYSTEM.CHANNEL.INITQ) +
trigdata(INTV1.MT.C) +
trigtype(FIRST) +
usage(XMITQ)
* Creamos la cola de recepción de mensajes
def ql (INTV1.Q.RX) +
descr('Cola local de Recepcion de INTV1') +
defpsist(YES) +
put(ENABLED) +
usage(NORMAL)
* Creamos la cola de recepción de notificaciones
def ql (INTV1.Q.RX) +
descr('Cola local de Notificaciones de INTV1') +
defpsist(YES) +
put(ENABLED) +
usage(NORMAL)
* Creamos la cola de recepción de rechazados
def ql (INTV1.Q.RECH) +
descr('Cola local de Rechazados de INTV1') +
defpsist(YES) +
put(ENABLED) +
usage(NORMAL)
* Creamos el canal de transmisión
def chl (INTV1.MT.C) chltype (SDR) +
trptype(TCP) +
conname(123.123.123.123) +
convert(YES) +
xmitq(HOST.INTV1.Q) +
descr('Canal de Transmision de INTV1') +
longtmr(60) +
shortrty(60) +
shorttmr(10)
* Creamos el canal de recepción
def chl (INTV1.MO.C) chltype (RCVR) +
trptype(TCP) +
descr('Canal de Recepcion de INTV1') |
Regards
Petter |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Dec 20, 2004 1:55 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
You should have 2 qmgrs, INTV1.QM & PAM.QM.
INTV1.QM hosts the remote queue, the xmitq, and the SDR channel
PAM.QM hosts the local queue specified in the RNAME attribute of the QR on INTV1.QM, and a RCVR channel of the same name as the SDR on INTV1.QM.
You should put the msg to the INTV1.Q.TX queue, the remote queue. This will cause the msg to be put to the xmitq HOST.INTV1.Q with the proper header.
Clear the xmitq with the runmqsc command CLEAR QL(HOST.INTV1.Q), so that the channel will trigger when the msg is put to the xmitq. If the channel does not start and flow the msg to the queue INTV1.Q.RX on qmgr PAM.QM, check:
the qmgr is running
there is a RCVR channel on PM.QM called INTV1.MT.C
there is a local queue on PAM.QM called INTV1.Q.RX
there is a listener running on the machine with IP address 123.123.123.123, listening on port 1414, for qmgr PAM.QM |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Mon Dec 20, 2004 2:06 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
hmmm...
well the other QM (PAM...) is up and running... i can receive messages from them... i got this config/set up file from them... put cant seem to send anything...
can i monitor the remote queue, to see if anything stacks up there??
or can i send some "command" to the remote queue, just to check if its up??
strange...
thanks, I have to look into it...
Petter |
|
| Back to top |
|
|
| Nigelg |
| Posted: Mon Dec 20, 2004 3:02 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Come on, get a grip...
You have to put the msg to the remote queue on INTV1.QM:
amqsput INTV1.Q.TX INTV1.QM
The msg will be put to the xmitq HOST.INTV1.Q
If the channel is running, the msg will be sent to queue INTV1.Q.RX on qmgr PAM.QM
If the channel is not running and the depth of the xmitq is 0, the channel will be trigger started
If the channel is not running and the depth is > 0, the msg will remain on the xmitq.
You cannot monitor the remote queue on INTV1.QM; that is only used to specify that the msg is to be put to the xmitq in the definition.
You can monitor the xmitq; runmqsc DIS QL(HOST,INTV1.Q)
You can check the channel; runmqsc DIS CHS(INTV1.MT.C)
Please read the Intercomms manual to get the basics of WMQ channels, including definitions of:
Local Queue
Remote Queue
Transmission Queue
SDR Channel
RCVR Channel
You MUST get a grasp of the basic concepts by reading and study. |
|
| Back to top |
|
|
| knegarpetter |
| Posted: Mon Dec 20, 2004 4:53 am Post subject: |
|
|
Apprentice
Joined: 10 Dec 2004
Posts: 39
|
Thanks great!
now I know how to do it.
if the remote PAM:intv1.q.rx is stacking up with my messages, is there ANY way i can "know" that from my side?.. .
I managed to put messages on the outgoing queue, they get sent by the intv1.mt.c, but then nothing. no respons, or no logging in the error log...
just wondering.
Petter |
|
| Back to top |
|
|
|
|
