| Author |
Message
|
| rebornspririt |
 Posted: Tue Aug 02, 2005 3:56 am Post subject: Very slow inactive channel startup on first message |
 |
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
This is actually a partual repost of http://www.mqseries.net/phpBB2/viewtopic.php?t=23467
The problem I'm having is that it takes very long (up to 30 seconds) before a message sent to an inactive channel is actually sent through that channel. I'm new to MQSeries and I have no idea what startups times I should consider as normal for an inactive channel to come up.
I aleady set the retry intervals to '1' (which I guess is 1 second). So I guess that the time (almost 30 seconds) that is needed to sent the message through is lost in the activation of the queue? I could live with 15 seconds for the first message, but, more than that is not acceptable for our environment.
Can anyone give me some pointers why the startup of an inactive queue in combination with the message sending takes that long.
Thanks in advance |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Tue Aug 02, 2005 4:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You really should read the Intercommunications manual.
And make sure you've read the parameter descriptions in the MQSC manual for DEFINE/ALTER channel, so you know what you are actually setting and what ranges it is in.
Maybe you should consider not allowing the channel to go inactive.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| rebornspririt |
| Posted: Tue Aug 02, 2005 6:12 am Post subject: Document url |
|
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
| Can you give me an url where I can find that piece of documentation. |
|
| Back to top |
|
|
| mq_crazy |
| Posted: Tue Aug 02, 2005 6:14 am Post subject: |
|
|
Master
Joined: 30 Jun 2004
Posts: 295
|
|
| Back to top |
|
|
| rebornspririt |
| Posted: Tue Aug 02, 2005 6:42 am Post subject: Pdf ? |
|
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
Is there also a pdf version of this document?
I'm not eager to complain but refering someone 'only' to some form of documentation is not the intension of forum I thought? I know I new to all of this but I realy do not have the time to read every possible MQ manual until I have the answer.
Not allowing the channel to go inactive is one of the possibilities but before going up that road I want to know what the problem us that it takes up to 30 seconds before a message gets through an inactive channels? I quickly viewed the html intercommunication doc but I'm not sure I'm looking at the correct place. I see how a channels goes from inactive to running ... but I don't see what happens with the message that has been sent to that channel when it was inactive.
So if possible some help here would be great. I would like to know what happens behind the scenes so I can solve the 30 second problem because I don't think .. I hope ... this is not 'normal' mq behaviour.
Thanks in advance |
|
| Back to top |
|
|
| JT |
| Posted: Tue Aug 02, 2005 9:14 am Post subject: |
|
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
|
| Back to top |
|
|
| wschutz |
| Posted: Tue Aug 02, 2005 9:31 am Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
and what "state" is the channel in during this initial 30 second interval? ie, is it "binding", "running", "retrying" ?
_________________
-wayne |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Aug 02, 2005 9:32 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
30 seconds does seem a little excessive, but there are many considerations to take into account, many of them network related (like firewalls, router configurations etc.) All I can tell you is that our triggered channels usually deal with things within 3 seconds max.
As for what happens.
Your application puts a message onto a queue that is defined as a remote queue. MQ knows this isn't a 'real' queue on the connected queue manager and he places it on the corrrect transmission queue (XMITQ).
If the channel associated with that transmission queue is active, then the message is sent across the channel immediately. If the channel is inactive and the XMITQ is not triggered...then the message sits on the XMITQ unitl it either expires, or the channel is started.
If the XMITQ is triggered, and assuming that all the conditions for triggering have been met then the queue manager generates a trigger message that is consumed by the channel initiator which will result in MQ issuing an internal start command for the channel and then the message is sent across the channel.
This is a very simplistic overview. There are many other things to consider. If you never want a channel to disconnect (go inactive) then change the DISCINT to 0, but be warned, this can also lead to its own issues.
The pros and cons of triggered channels v's non triggered channels, disconnect and retry intervals has been covered in other threads.
Here is one of them
http://www.mqseries.net/phpBB2/viewtopic.php?t=4721&start=0&postdays=0&postorder=asc&highlight=discint%20trigger
When you were pointed to the Intercommunications manual the person wasn't being rude. It is my contention that if you are going to read only one MQ manual, then this is the one to read. Once you 'get' what it is telling you, then you are well on your way to having a working knowledge of MQ remote queueing and all its foibles.  |
|
| Back to top |
|
|
| hopsala |
| Posted: Tue Aug 02, 2005 11:53 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
As Kevin said, this is not normal MQ behavior, channels usually go from inactive to running in a few seconds.
A good way to pinpoint the problem would be:
1. Create a second qmgr on the same machine, and define a new sdr-rcvr pair between the original qm and the one you just created. This will tell you if the prob is comm oriented or something local.
2. If the local sdr-rcvr pair is ok, but the remote pair is still acting up, try starting the channel without any msgs in the xmitq. Or maybe try creating another remote qmgr on the same remote machine and working with it.
3. Naturally, the first thing you should do is look at the logs at /var/mqm/errors/AMQERR01.LOG and /var/mqm/qmgrs/QMNAME/errors/AMQERR01.LOG (this is unix, if in win change /var/mqm to c:\program files\ibm)
(p.s for more info on the topic of triggered channels, see "Intercommunication" manual on chapter 9, and "Application programming guide" chapter 14)
concerning the "read the manual" issue, since mq is rather a complex topic, which takes some time to learn, it is rather difficult (possibly impossible) to explain all the options mq provides in forum format. Also, mq lit is surprisingly clear and you will receive a better, more comprehensive explanation to any q there than you will here. It seems unproductive to keep repeating what's already explained.
In general (from what I noticed, i'm not a moderator) there is a custom here not to answer anything to which the answer is clearly stated in the manuals, so the reply kevin just gave you was rather unusual and kind-hearted of him. My answer is more customary - tips towards the solution with the assumption of previous mq knowledge.
Usually, since we can never have sufficient knowledge of your specific site and problem, it is better for you and all to read, see all the possible options, and decide which is most appropriate for you. Any q beyond the manual, will be happily received.
Of course, it would be beneficial using the "search" button at the top of the screen before posting... |
|
| Back to top |
|
|
| rebornspririt |
| Posted: Tue Aug 02, 2005 10:50 pm Post subject: Channel definitions |
|
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
Thanks guys this was really useful.
I have now a basic understanding of what is happening behind the scene and will take some time to read the intercommunication document 
Both queue managers with their channels are on the same machine. This is done because its a kind of test environment where the second queue manager simulates some other company's backend until we have its real connection.
Now I would like to post my channel / queue definition here like some of you suggested previously but .... how do I do that, can I export these configuration settings and if so how can I do this?
I have taken a look at the error log, nothing special in there.
Thanks[/b] |
|
| Back to top |
|
|
| rebornspririt |
| Posted: Tue Aug 02, 2005 11:47 pm Post subject: Logging |
|
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
| Is it possibile to log the exact time when the channel goes from one state (inactive) to another (running)? Because I would like to know which end is acting too slow. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 03, 2005 4:23 am Post subject: Re: Logging |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| rebornspririt wrote: |
| Is it possibile to log the exact time when the channel goes from one state (inactive) to another (running)? Because I would like to know which end is acting too slow. |
Look in the AMQERR0*.logs. As channels stop and start, that info is captured there.
To post the definitions, open up a RUNMQSC session on the QM and use the DIPSLAY CHANNEL command for the relevent channels. Copy and paste the ouput here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rebornspririt |
| Posted: Wed Aug 03, 2005 5:15 am Post subject: Additional information |
|
|
Newbie
Joined: 29 Jul 2005
Posts: 9
|
I'm not sure what extra information this gives you ... but good luck 
Sending queue manager:
-----------------------------
sender:
---------
- CHANNEL(MSP2_DEV.TO.ING_SIM)
- TRPTYPE(TCP)
- XMITQ(T.MSP2_DEV.TO.ING_SIM)
- MODENAME( )
- BATCHSZ(50)
- SHORTRTY(10)
- LONGRTY(10)
- SCYEXIT( )
- MAXMSGL(4194304)
- SCYDATA( )
- PASSWORD( )
- CONNAME(localhost (1445))
- BATCHINT(0)
- MCAUSER( )
- ALTTIME(10.30.04)
- MSGEXIT
- SENDEXIT( )
- RCVEXIT( )
- MSGDATA( )
- SENDATA( )
- RCVDATA( )
- CHLTYPE (SDR)
- DESCR( )
- MCANAME( )
- TPNAME( )
- DISCINT(6000)
- SHORTTMR(1)
- LONGTMR(1)
- SEQWRAP(999999999)
- CONVERT(NO)
- USERID( )
- MCATYPE(PROCESS)
- HBINT(10)
- NPMSPEED(FAST)
- ALTDATE(2005-08-03)
receiver:
----------
- CHANNEL(ING_SIM.TO.MSP2_DEV)
- TRPTYPE(TCP)
- BATCHSZ(50)
- SEQWRAP(999999999)
- PUTAUT(DEF)
- MREXIT( )
- MRRTY(10)
- HBINT(10)
- MCAUSER( )
- ALTTIME(10.30.04)
- MSGEXIT( )
- SENDEXIT( )
- RCVEXIT( )
- MSGDATA( )
- SENDATA( )
- RCVDATA( )
- CHLTYPE (RCVR)
- DESCR( )
- SCYEXIT( )
- MAXMSGL(4194304)
- SCYDATA( )
- MRDATA( )
- MRTMR( )
- NPMSPEED(FAST)
- ALTDATE(2005-08-03)
Queue manager:
-------------------
- DESCR( )
- DEFXMITQ(T.MSP2_DEV.TO.ING_SIM)
- CLWLEXIT( )
- REPOS( )
- COMMANDQ(SYSTEM.ADMIN.COMMAND.QUEUE)
- MAXHANDS(256)
- AUTHOREV(ENABLED)
- LOCALE(ENABLED)
- PERFMEV(ENABLED)
- CHAD(DISABLED)
- CLWLLEN(100)
- CCSID(437)
- CMDLEVEL(510)
- SYNCPT
- DEADQ(SYSTEM.DEAD.LETTER.QUEUE)
- CHADEXIT( )
- CLWLDATA( )
- REPOSNL( )
- TRIGINT(999999999)
- MAXUMSGS(10000)
- INHIBTEV(ENABLED)
- REMOTEEV(ENABLED)
- STRSTPENV(ENABLED)
- CHADEV(DISABLED)
- MAXMSGL(4194304)
- MAXPRTY(9)
- DISTL(YES)
The receiving queue manager is configured with the same settings. If more information is needed just let me know
Thanks |
|
| Back to top |
|
|
|
|
