| Author |
Message
|
| nickj |
 Posted: Thu Mar 02, 2017 2:05 pm Post subject: MQ Channels Stay Asleep/Inactive Even With Msg In TX Queue? |
 |
|
Newbie
Joined: 02 Mar 2017
Posts: 4
|
Hey there,
First just wanted to say what a great resource to find, really appreciate everyone's efforts here to help people out!
I've very much benefitted from the answers all of you have dedicated your time to providing, so thanks again!
A quick question, and more some guidance on what concept/part of the MQ Guide I should be looking at:
What settings are available on the channel to ensure that a channel automatically wakes up when there are messages sitting on it's transmission queue?
Right now, it stays asleep/inactive, and I need to login with the Explorer to switch to Start and then everything goes along nicely on the Sender, and receive the subsequent response...?
EDIT
Looks like I've done a bit more research, am I on the right path by just setting up the Transmission Queue Triggering like follows:
Trigger Data (TRIGDATA) = <Name of Channel I want to start>
Initiation Queue (INITQ) = SYSTEM.CHANNEL.INITQ
Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending?
Thanks again in advance,
Nick
 |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Mar 02, 2017 3:07 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Trigtype(first) is sufficient). The other requirement is a started channel initiator.
_________________
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 |
|
|
| gbaddeley |
| Posted: Thu Mar 02, 2017 3:49 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Check that transmission queue has
usage(xmitq)
trigtype(first)
trigger
initq('SYSTEM.CHANNEL.INITQ')
trigdata('yoursenderchannelname')
maxmsgl also needs to be large enough for your largest message + size of mqxqh header
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Mar 02, 2017 11:05 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Look in the error logs for the qmgr whose sender chl fails to start Post errors here.
_________________
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 |
|
|
| exerk |
| Posted: Fri Mar 03, 2017 2:59 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
And you may have to reset the trigger, e.g. ALTER QL(BLAH) NOTRIGGER followed by ALTER QL(BLAH) TRIGGER, or do it through MQ Explorer as you intimate you're using that.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 03, 2017 5:38 am Post subject: Re: MQ Channels Stay Asleep/Inactive Even With Msg In TX Que |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| nickj wrote: |
| Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending? |
To expand on the comment of my most worthy associate:
You should use "First" not "Every". As a well behaved MQ application, the channel MCA will, once started, continue to run until the transmission queue is empty. Because "First" was chosen as a shorter way of writing "when the queue depth goes from 0 to 1", the next message to arrive on an empty queue will cause the "First" trigger to fire (assuming the MCA has stopped at this point).
If you use "Every", a new instance of the MCA will be triggered for each message that arrives. This will cause pain, suffering, madness and lots of error messages as they fight it out for access to the queue, as well as a lot of error messages from the poor confused MCA at the other end which expects a well mannered conversation over the channel and is instead confronted with this yelling crowd.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Mar 05, 2017 3:37 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| Am I right in assuming that the trigger type should be set to "Every" and not "First", as I intend on any new message arriving to trigger the channel sending? |
Never use trigtype(every) on transmission queues, for reasons given above. If the channel is not starting when the first msg appears on the xmitq, you need to identify the reason and fix it.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Mar 05, 2017 8:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Look for possible clues in errors logs.
_________________
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 |
|
|
| nickj |
| Posted: Wed Mar 08, 2017 4:41 pm Post subject: |
|
|
Newbie
Joined: 02 Mar 2017
Posts: 4
|
Thanks all for your replies, sorry for my tardiness, I had the week off work...back to it now (the joy!)
So I looked further into it, and I didn't have the channel initiator setup initially as suggested by bruce2359 thanks!
I've done that now, and on queue manager restart/start/stop the ChannelInitiator service is starting:
| Code: |
mqm 175 0.0 1.1 360648 11452 ? Sl 11:25 0:00 /opt/mqm/bin/runmqchi -m COOLQMGR1 -q SYSTEM.CHANNEL.INITQ -r
|
AND the channel initiator kicks and sends the messages from the TQ like it's meant to, but despite it all seeming to be working fine, I'm still getting some weird errors when restarting the QM (which restarts the CI service), implying it is trying to start the service twice again?
| Code: |
-------------------------------------------------------------------------------
03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi)
Host(ramzihacker) Installation(Installation1)
VRMF(9.0.1.0) QMgr(COOLQMGR1)
AMQ8024: IBM MQ channel initiator started.
EXPLANATION:
The channel initiator for queue SYSTEM.CHANNEL.INITQ has been started.
ACTION:
None.
-------------------------------------------------------------------------------
03/09/17 11:00:24 - Process(180.1) User(root) Program(runmqchi)
Host(ramzihacker) Installation(Installation1)
VRMF(9.0.1.0) QMgr(COOLQMGR1)
AMQ9509: Program cannot open queue manager object.
EXPLANATION:
The attempt to open either the queue or queue manager object
'SYSTEM.CHANNEL.INITQ' on queue manager 'COOLQMGR1' failed with reason code
2042.
ACTION:
Ensure that the queue is available and retry the operation.
|
Some more info:
Sender Channel Config
| Code: |
DISPLAY CHL(COOLQMGR1.TO.ANOTHERQMGR)
1 : DISPLAY CHL(COOLQMGR1.TO.ANOTHERQMGR)
AMQ8414: Display Channel details.
CHANNEL(COOLQMGR1.TO.ANOTHERQMGR) CHLTYPE(SDR)
ALTDATE(2017-03-09) ALTTIME(10.26.17)
BATCHHB(0) BATCHINT(0)
BATCHLIM(5000) BATCHSZ(50)
CERTLABL( ) COMPHDR(NONE)
COMPMSG(NONE) CONNAME(123.456.789.123(1414))
CONVERT(NO) DESCR(TEST)
DISCINT(5) HBINT(300)
KAINT(AUTO) LOCLADDR( )
LONGRTY(999999999) LONGTMR(1200)
MAXMSGL(4194304) MCANAME( )
MCATYPE(PROCESS) MCAUSER( )
MODENAME( ) MONCHL(QMGR)
MSGDATA( ) MSGEXIT( )
NPMSPEED(FAST) PASSWORD( )
PROPCTL(COMPAT) RCVDATA( )
RCVEXIT( ) RESETSEQ(NO)
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SEQWRAP(999999999) SHORTRTY(10)
SHORTTMR(60)
SSLCIPH(TLS_RSA_WITH_AES_256_CBC_SHA256)
SSLPEER( ) STATCHL(QMGR)
TPNAME( ) TRPTYPE(TCP)
USEDLQ(YES) USERID( )
XMITQ(TRANS.OK.TEST)
|
Transmission Queue Config
| Code: |
DISPLAY QUEUE(TRANS.OK.TEST)
31 : DISPLAY QUEUE(TRANS.OK.TEST)
AMQ8409: Display Queue details.
QUEUE(TRANS.OK.TEST) TYPE(QLOCAL)
ACCTQ(QMGR) ALTDATE(2017-03-08)
ALTTIME(23.06.32) BOQNAME( )
BOTHRESH(0) CLUSNL( )
CLUSTER( ) CLCHNAME( )
CLWLPRTY(0) CLWLRANK(0)
CLWLUSEQ(QMGR) CRDATE(2017-03-08)
CRTIME(01.37.10) CURDEPTH(0)
CUSTOM( ) DEFBIND(OPEN)
DEFPRTY(0) DEFPSIST(YES)
DEFPRESP(SYNC) DEFREADA(NO)
DEFSOPT(SHARED) DEFTYPE(PREDEFINED)
DESCR(Transmission Queue for OK TEST)
DISTL(YES) GET(ENABLED)
HARDENBO INITQ(SYSTEM.CHANNEL.INITQ)
IPPROCS(0) MAXDEPTH(5000)
MAXMSGL(4194304) MONQ(QMGR)
MSGDLVSQ(PRIORITY) TRIGGER
NPMCLASS(NORMAL) OPPROCS(0)
PROCESS( ) PUT(ENABLED)
PROPCTL(COMPAT) QDEPTHHI(80)
QDEPTHLO(20) QDPHIEV(DISABLED)
QDPLOEV(DISABLED) QDPMAXEV(ENABLED)
QSVCIEV(NONE) QSVCINT(999999999)
RETINTVL(999999999) SCOPE(QMGR)
SHARE STATQ(QMGR)
TRIGDATA(COOLQMGR1.TO.ANOTHERQMGR) TRIGDPTH(1)
TRIGMPRI(0) TRIGTYPE(FIRST)
USAGE(XMITQ)
|
|
|
| Back to top |
|
|
| PaulClarke |
| Posted: Wed Mar 08, 2017 6:09 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
If RUNMQCHI is getting 2042's when it tries to open the SYSTEM.CHANNEL.INITQ queue that's not good. This queue is used to accumulate the trigger messages as well as a variety of others. Channel triggering is not going to work if the initiator can't even open the initiation queue.
I can only imagine that you have some other program that has opened this queue erroneously. Issue a command like:
DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE) to see what application has opened the queue.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| nickj |
| Posted: Wed Mar 08, 2017 7:24 pm Post subject: |
|
|
Newbie
Joined: 02 Mar 2017
Posts: 4
|
Thanks Paul, the channel triggering was working, but still getting those logs show up every now and then, despite everything "working".
I just restarted the server/QMGR a few times and now it's working properly, without having that error in the logs (which wasn't really, maybe a temporary acccess issue)
When I ran the DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE), it was only the runmqchi that was using it anyway:
| Code: |
DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE)
1 : DIS QSTATUS(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE)
AMQ8450: Display queue status details.
QUEUE(SYSTEM.CHANNEL.INITQ) TYPE(HANDLE)
APPLDESC(IBM MQ Channel Initiator) APPLTAG(runmqchi)
APPLTYPE(CHINIT) BROWSE(NO)
CHANNEL( ) CONNAME( )
ASTATE(NONE) HSTATE(ACTIVE)
INPUT(EXCL) INQUIRE(NO)
OUTPUT(NO) PID(175)
QMURID(0.0) SET(YES)
TID(1)
URID(XA_FORMATID[] XA_GTRID[] XA_BQUAL[])
URTYPE(QMGR) USERID(root)
|
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Mar 08, 2017 7:43 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
My diagnosis (from NZ) is that the other ci's we're the ones you started manually while trying to kick-start the channel. No harm, no foul.
_________________
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 |
|
|
| gbaddeley |
| Posted: Thu Mar 09, 2017 3:37 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| Quote: |
| 03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi) |
All MQ qmgr processes should be running as mqm.
runmqchi is supposed to start when the qmgr starts. You shouldn't need to start it manually.
_________________
Glenn |
|
| Back to top |
|
|
| nickj |
| Posted: Thu Mar 09, 2017 4:09 pm Post subject: |
|
|
Newbie
Joined: 02 Mar 2017
Posts: 4
|
| gbaddeley wrote: |
| Quote: |
| 03/09/17 11:00:24 - Process(175.1) User(root) Program(runmqchi) |
All MQ qmgr processes should be running as mqm.
runmqchi is supposed to start when the qmgr starts. You shouldn't need to start it manually. |
Yep, you're not wrong, that's exactly what triggers the weird logs, despite everything working.
Thanks again everyone for your help with this one!
Cheers,
Nick |
|
| Back to top |
|
|
|
|
