| Author |
Message
|
| N |
 Posted: Wed Nov 12, 2008 1:58 am Post subject: Auto Start MQ Channel for windows/unix |
 |
|
Acolyte
Joined: 21 Jul 2007
Posts: 64
|
Hi,
Any1 knows how to set AUTO START Attribute for sender channel? My sender channel become 'inactive' when the machine re-boot.
 |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed Nov 12, 2008 2:18 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If your XMITQ is set to be triggered then your SDR channel will 'auto-start' once messages arrive on the XMITQ.
After the DISCINT interval expires, and no messages have arrived on the XMITQ within that interval, the channel will return to INACTIVE until a message again arrives on the XMITQ, thereby starting the triggering process again.
This will ensure you do not have to start the channel manually, even after queue manager restart, or server reboot.
_________________
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 |
|
|
| AkankshA |
| Posted: Wed Nov 12, 2008 2:44 am Post subject: |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
if resorces are not a problem.. you can set DISINT to "0"
channel shall remain in active state always
_________________
Cheers |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 12, 2008 4:26 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| AkankshA wrote: |
| if resorces are not a problem.. you can set DISINT to "0" |
And you trust your network completely.
| AkankshA wrote: |
| channel shall remain in active state always |
Unless the link drops in which case it will stop.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Nov 12, 2008 4:37 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
AkankshA,
How could you even suggest this is good faith? Nothing is perfect and eventually there will be a network error (a lot sooner then you think).
I look for this setting when conducting "Health Checks" and consider this an erroneous configuration. The channel needs to be configured to trigger to start correctly and if there are still know times when burst of messages will arrive, use cron (or the equivalent) to start the channel a few minutes before that known time. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 12, 2008 6:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Presupposing that there will be network errors, it seems to me that there is no difference if you use cron or triggered xmit queue to start your channels.
Scenario 1: the xmit queue is tirggered or not; cron tries to start the channel x minutes ahead of when you expect messages to arrive on the xmitq; a channel failure is detected; the channel fails to start.
Scenario 2: the xmit queue is triggered; messages arrive; a channel failure is detected; the channel fails to start.
If you cron 1 or 10 or 60 minutes ahead, the channel can still fail before messages arrive on the xmitq.
How is this better or different? Am I missing something 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 |
|
|
| Vitor |
| Posted: Wed Nov 12, 2008 7:40 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| How is this better or different? Am I missing something here? |
This assumes messages turn up on a regular basis and hence a cron can be scheduled. If the messages are intermittant, you save more resources with a triggered queue.
Another point - if the messages are time-critical you may not want to wait 10 or 60 mins for the cron to restart the channel.
Like many design decisions, no method is "better". It's simply better for your situation.
Of course, some design decisions are better for your situation is some bizzare alternate universe!!!
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Wed Nov 12, 2008 10:51 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
Really, this has been discussed nearly to death but I shall be brave and offer a comment anyway.
I do have some channels that are so consistently busy that I have the DISCINT set to 0. You could argue that, for a really busy channel, the DISCINT is a moot point, and that's probably a valid argument.
But even for a channel with DISCINT=0, I trigger the channels to cover such things as network drops, the target receiving server going down, server restarts, and so forth.
The point I'm aiming for is that a DISCINT=0 and a triggered XMITQ are not mutually exclusive concepts.....
I prefer the self-healing aspects of a triggered XMITQ to a cron job. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Nov 12, 2008 12:40 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You never ever never ever want that channel to end? 
Set DISCINT to 1 week, or 1 month, or 1 year. If you have a channel that hasn't had a message go over in a month, you probably don't need or want it running.
And N is probably asking why don't his/her channels come up running after a reboot, even if there are no messages in the XMITQ to trigger. N, the answer is "just because".  If there are no messages to move after a reboot, why do you need / or want the channels to come up running? Let them trigger once you finally get a mesage on the XMITQ after the reboot.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Nov 12, 2008 12:56 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
The false assumption that get us to this conversation: A channel in running state is capable of sending/receiving messages or is currently sending/receiving messages. (The IBM technical definition of running: transferring messages, or waiting for messages to arrive on the transmission queue.)
A running channel may be able to send/recieve a message. The only effective method of determining with any finality if it is possible to send a message is to successfully send a message. An as-yet undetected error may cause the channel to fail; thus retry count and interval settings.
The only channel state that can be reasonably believed to be true for a long(er) period of time is stopped. Stopped takes some kind of manual (automated) intervention. All the other channel states are transitory.
The underlying issue with an inactive state channel is: will it start? The answer is yes, no, it depends.
_________________
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 |
|
|
|
|
