Author |
Message
|
Bear |
Posted: Thu Dec 21, 2006 9:04 am Post subject: messages arriving on a TXQ do not trigger sender channel sta |
|
|
 Voyager
Joined: 17 Jan 2006 Posts: 28 Location: Montreal Canada
|
A transmission queue that has been set up for over a year will now will not trigger the start of a sender channel when messages arrive. The properties for the TXQ are set 'first'. The TXQ has been variously set at Trigger OFF then ON and messages cleared to test the arrival of messages. The channel can be started manually and pings are successful. About a month ago the QMGR was recycled and at that time we were getting AMQ2063 messages along with AMQ9508 messages and an indication that the repository manager ended abnormally (AMQ9509). The queue manager in question is not part of a cluster so not sure why the term repository is used. We are not now getting these errors whatsoever.
This is a production QMGR and we have temporarily set the disconnect interval to zero so it runs continuously.
When a status of the TXQ is performed there are several handles associated with it all related to user bea (Weblogic). I wanted to delete/redefine the TXQ to see if this will cure the problem but since this is a production QMGR that is not easy as it requires change tickets, management approval, etc.
We would like to get to the bottom of the problem rather then mess with the TXQ or recycle the QMGR. One hit on the IBM support site hinted at user id 'mqm' being defined locally as well as NIS+ defined. This is not the case here. Help from all and sundry greatly appreciated.
 |
|
Back to top |
|
 |
JosephGramig |
Posted: Thu Dec 21, 2006 9:42 am Post subject: |
|
|
 Grand Master
Joined: 09 Feb 2006 Posts: 1244 Location: Gold Coast of Florida, USA
|
Hmmm, is the xmit queue open for input or output?
If so, by what?
I believe that if you open it with a browse, you might cause the trigger to not trigger. This would be the case if you browsed it with one program to see what is in there.
If it is not open for anything, it should trigger on the next message arrival.
That is my recollection of this issue. _________________ Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
Back to top |
|
 |
Bear |
Posted: Thu Dec 21, 2006 10:37 am Post subject: |
|
|
 Voyager
Joined: 17 Jan 2006 Posts: 28 Location: Montreal Canada
|
Interesting what you say about opening for a browse but we have intentionally cleared any and all messages on the TXQ and sent new messages that would not have been browsed. We have get and put disabled the TXQ and then re enabled get and put, kinda like turning it off and on I suppose. Stop the channel, restarted the channel in both STOPPED mode and INACTIVE. Tried several combinations of settings of the property values, etc. etc. Thanks for your input _________________ Software Specialist |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Thu Dec 21, 2006 10:57 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
What Joseph means is, when the queue is opened, no trigger message will be generated.
There are lots of further trigger conditions:
- Is the channel initiator running.
- Did you specify the channel name in the TRIGDATA field of the XmitQ.
- Did you specify the SYSTEM.CHANNEL.INITQ in the INITQ field of the XmitQ.
- Are any uncommitted messages in the XmitQ.
- The XmitQ must not be opened already (because the channel tries an exclusive open).
- The channel must not be STOPPED.
Did I forget something? _________________ Regards
Hubert |
|
Back to top |
|
 |
killer |
Posted: Thu Dec 21, 2006 2:51 pm Post subject: |
|
|
 Apprentice
Joined: 06 Jul 2006 Posts: 35
|
check the channel attributes too.
Especially,BatchSz field.
May be ,Channel is not able to commit the batch of messages. |
|
Back to top |
|
 |
wschutz |
Posted: Thu Dec 21, 2006 3:37 pm Post subject: |
|
|
 Jedi Knight
Joined: 02 Jun 2005 Posts: 3316 Location: IBM (retired)
|
Can you do a display of the xmitq?
What version/fix level of MQ?
What OS? _________________ -wayne |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Thu Dec 21, 2006 10:56 pm Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
killer wrote: |
check the channel attributes too.
Especially,BatchSz field.
May be ,Channel is not able to commit the batch of messages. |
Good idea, you should also check the error logs on the receiving QMgr. May be, the logs are too small. check for any "transaction rolled back" message. _________________ Regards
Hubert |
|
Back to top |
|
 |
Bear |
Posted: Thu Jan 04, 2007 7:00 am Post subject: |
|
|
 Voyager
Joined: 17 Jan 2006 Posts: 28 Location: Montreal Canada
|
Greetings and Happy New Year!!
I have been away during the holidays so I have responded to all the great suggestions. "I was making rather merry" during Christmas.
I checked the batch size as suggested: OK. Essentially we are do loopback testing with only 1 or 2 small messages. I have displayed the TXQ as suggested below. I have yet to check the logs on the receiving side as it is on our z/OS platform and I don't have access but will check with the Sys. types this AM. Since this is a production support Queue Manager I cannot recycle the qmgr without great consternation, nor can I dump the MQ System logs but I did do an eyeball scan looking for tell tale signs but to no avail, no sign of anything untowards. I think I have exhausted most possibilities but I would much appreciate any other suggestions before I tackle IBM and have to create and PMR. Once again thanks to all. Our server for this qmgr is a Solaris 5.9, MQ V5.3 with CSD 11. Here's the queue printout.
2 : dis ql(MQE4) all
AMQ8409: Display Queue details.
DESCR(WebSphere MQ Default Local Queue)
PROCESS( ) BOQNAME( )
INITQ(SYSTEM.CHANNEL.INITQ) TRIGDATA(MQESRC1_MQE4)
CLUSTER( ) CLUSNL( )
QUEUE(MQE4) CRDATE(2007-01-03)
CRTIME(09.59.27) ALTDATE(2007-01-04)
ALTTIME(09.31.2 GET(ENABLED)
PUT(ENABLED) DEFPRTY(0)
DEFPSIST(YES) MAXDEPTH(999999999)
MAXMSGL(4194304) BOTHRESH(0)
SHARE DEFSOPT(SHARED)
HARDENBO MSGDLVSQ(FIFO)
RETINTVL(999999999) USAGE(XMITQ)
TRIGGER TRIGTYPE(FIRST)
TRIGDPTH(1) TRIGMPRI(0)
QDEPTHHI(80) QDEPTHLO(20)
QDPMAXEV(ENABLED) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QSVCINT(999999999)
QSVCIEV(NONE) DISTL(NO)
NPMCLASS(NORMAL) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(0)
OPPROCS(2) CURDEPTH(1)
dis qs(MQE4) all
3 : dis qs(MQE4) all
AMQ8450: Display queue status details.
QUEUE(MQE4) IPPROCS(0)
OPPROCS(2) CURDEPTH(1)
UNCOM(NO)
 _________________ Software Specialist |
|
Back to top |
|
 |
KevinF23492 |
Posted: Thu Jan 04, 2007 7:24 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006 Posts: 22
|
Quote: |
CRDATE(2007-01-03) |
Now wait a cotton picking minute here. How can this be the same as the one you started sicussing on 21st Dec
Now....I notice you have 2 process got this open for output this leads me to ask this question.
You aren't putting messages directly onto this queue are you?
This is used purely as a transmission queue on a remote queue definition right? |
|
Back to top |
|
 |
Nigelg |
Posted: Thu Jan 04, 2007 7:24 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
Clearly it will not trigger now because the xmitq has CURDEPTH(1) and TRIGGER(FIRST). _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
KevinF23492 |
Posted: Thu Jan 04, 2007 7:30 am Post subject: |
|
|
Novice
Joined: 26 Dec 2006 Posts: 22
|
Quote: |
Clearly it will not trigger now because the xmitq has CURDEPTH(1) and TRIGGER(FIRST). |
Unless the display was done after it didn't trigger.  |
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Thu Jan 04, 2007 8:03 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Nigelg wrote: |
Clearly it will not trigger now because the xmitq has CURDEPTH(1) and TRIGGER(FIRST). |
An
Quote: |
ALTER QL(...) NOTRIGGER |
followed by an
Quote: |
ALTER QL(...) TRIGGER |
should force a trigger message. _________________ Regards
Hubert |
|
Back to top |
|
 |
Bear |
Posted: Thu Jan 04, 2007 8:10 am Post subject: |
|
|
 Voyager
Joined: 17 Jan 2006 Posts: 28 Location: Montreal Canada
|
SRRY! I sent a printout of the queue when I still had a test message in it. I should have cleared it before I displayed it!!
I had been sending messages to the TXQ off and on but always cleared before the next test. Anyway, if one sets trigger off and get disabled and then switches them on and enabled, respectively, then the TXQ should trigger the channe, not so! _________________ Software Specialist |
|
Back to top |
|
 |
bbburson |
Posted: Thu Jan 04, 2007 8:15 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004 Posts: 378 Location: Nowhere near a queue manager
|
KevinF23492 wrote: |
You aren't putting messages directly onto this queue are you?
This is used purely as a transmission queue on a remote queue definition right? |
|
|
Back to top |
|
 |
HubertKleinmanns |
Posted: Thu Jan 04, 2007 8:38 am Post subject: |
|
|
 Shaman
Joined: 24 Feb 2004 Posts: 732 Location: Germany
|
Does your QMgr have a Dead Letter Queue specified? _________________ Regards
Hubert |
|
Back to top |
|
 |
|