Author |
Message
|
rachakonda_v |
Posted: Fri May 10, 2013 10:22 am Post subject: Always keep Channel in running state |
|
|
Newbie
Joined: 14 Jun 2012 Posts: 7
|
Hello All,
I want to keep the channel in up and running always, When I start the channel it is running but after some time it is going to INACTIVE state.
Can anybody suggest me to fix this issue permanently.
Vamsi. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Fri May 10, 2013 10:42 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Why do you want it running always? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
Vitor |
Posted: Fri May 10, 2013 10:51 am Post subject: Re: Always keep Channel in running state |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
rachakonda_v wrote: |
Can anybody suggest me to fix this issue permanently. |
What issue? Functioning as designed and while you can change the behavior it's not (as my most worthy associate infers) not that great an idea. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
zpat |
Posted: Fri May 10, 2013 1:47 pm Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
You can set a disconnect interval of zero.
The only advantage of this that I can see, is that any communications failure is made immediately apparent, rather than only becoming obvious the next time the channel starts up.
So conceivably this could allow time to fix the comms problem before the channel is next needed (e.g. over a weekend) rather than finding out on Monday morning that there is a problem. |
|
Back to top |
|
 |
mqjeff |
Posted: Fri May 10, 2013 5:02 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
zpat wrote: |
You can set a disconnect interval of zero.
The only advantage of this that I can see, is that any communications failure is made immediately apparent, rather than only becoming obvious the next time the channel starts up.
So conceivably this could allow time to fix the comms problem before the channel is next needed (e.g. over a weekend) rather than finding out on Monday morning that there is a problem. |
One would usually expect that the network team had a better tool to monitor their systems than a queue manager. |
|
Back to top |
|
 |
Vitor |
Posted: Fri May 10, 2013 5:05 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
zpat wrote: |
You can set a disconnect interval of zero.
The only advantage of this that I can see, is that any communications failure is made immediately apparent, rather than only becoming obvious the next time the channel starts up.
So conceivably this could allow time to fix the comms problem before the channel is next needed (e.g. over a weekend) rather than finding out on Monday morning that there is a problem. |
So you'd come into the office on a Saturday to check the channels were running? Otherwise the first time you'd find out this long running channel wasn't working was when you tried to use it Monday morning. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri May 10, 2013 5:36 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
RUNNING state means EITHER that the channel is currently transmitting messages, OR that it believes that it will be able when next it tries. It won't know for sure if it can until it tries. When next it tries, it may find out that the channel is unable to transmit. _________________ 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 |
|
 |
PeterPotkay |
Posted: Sat May 11, 2013 5:33 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Heartbeats would identify a network problem on a running channel even if there were no application messages to send.
Monitor and Alerting can save you the trip into the office Saturday to see if the channels are up or not.
Having a channel run all the time when there are no messages to send for long periods of times wastes resources. And can lead to unnecessary alerts to the MQ team. If you have the channel running all night even though there are no messages to send, and the network goes down for 30 minutes, why get paged? If the channel was Inactive you would have never known there was a temporary problem in the middle of the night.
Keeping cluster channels running all the time might be needed if you can't absorb the overhead of a channel going from Inactive to Running. During that brief time messages don't flow over that channel. If you have extremely time sensitive messages maybe you want to do everything you can to avoid a channel cycling from Inactive to Initializing to Starting to Binding to Running. Or if you are using CLWLPRTY on the cluster receiver channels you might want to keep all channels running all the time, because an Active channel but lower priority channel will be chosen by the cluster over an Inactive but higher priority channel, rarely the intention when setting up CLWLPRTY.
Or maybe the OP doesn't understand that MQ will automatically start a cluster channel when that channel has work to do.
So back to the original question, why do you want the channels running all the time? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
zpat |
Posted: Mon May 13, 2013 1:39 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Our Qpasa monitor would alert on the channel not working. Network monitoring is another issue entirely - it might or might not detect every problem that can affect a MQ channel.
For example if a firewall rule was accidentally deleted - and stopped the channel connecting, I don't think any other alerting would catch this (and this has happened to me).
In any case it wouldn't be the first time that a MQ channel problem was the first symptom (and the first to report) a network issue.
Anyway - this usefulness (or not) comes for free - so I don't see the problem with using it if you are not bothered about the (small amount) of resources used by an active channel.
I am not saying it is a good idea (and we don't generally do it) but it is a possible reason. |
|
Back to top |
|
 |
cicsprog |
Posted: Tue May 28, 2013 8:02 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002 Posts: 347
|
I'd bet money they don't have their XMITq and Sender Channel configured properly to trigger the channel to start when messages need to flow. I've seen newbie MQ Admins think the channel always must be RUN.
You should check your XMITq is configure properly for triggering the channel to start when messages hit the XMITq. You WANT to have channels go INACTIVE when message are not going across the channel. If you have the triggering attributes configured properly on the XMITq, your channel will start when it needs to start.
This was posted under clustering but sounds like a point to point config. Poster needs to clarify. |
|
Back to top |
|
 |
|