| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Channel retrying on first start |
« View previous topic :: View next topic » |
| Author |
Message
|
| MichaelBulla |
 Posted: Tue May 20, 2008 2:29 am Post subject: Channel retrying on first start |
 |
|
Apprentice
Joined: 27 Sep 2006
Posts: 31
Location: Hamburg/Germany
|
Hello,
I have a problem configuring MQ.
What I want to do:
I configure a machine that should run at another place. I dont have access to the network, where the machine runs. So I configure the MQ server and put some messages to a transmitQ, that register the new instance in our application. When the server arrives at it destination it should just be plugged in and start working.
What works fine:
I install a MQ server on a machine create a transmission Q with a trigger, define a senderchannel and a receiver to another server and do all the stuff thats needed for intercommunications (on the other server too). After configuration I put some messages into the transmission Q and they are delivered. That way created connection works fine and is reliable even in case of network failure.
What doesnt work
I install a MQ server and do all the configuration in the same way, except I do it "offline". That means there is no ethernet-cable on the machine. After configuration I put some messages into the transmission Q and shut down MQ and the whole machine. After some days the machine is switched to the networked, and the machine and MQ server are started.
Now the senderchannel doesnt start and stays all the time in retrying-state until I start the channel manually. After the channel is startet manually everthing works fine.
But I want the channel to start automatically, so there is no additional work needed, when the server is startet first time. Any ideas what could be the problem?
Im using MQ 6 on SLES.
Bye Michael |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue May 20, 2008 2:50 am Post subject: Re: Channel retrying on first start |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MichaelBulla wrote: |
| So I configure the MQ server and put some messages to a transmitQ |
Never write directly to the transmission queue. If you do, be very certain the messages have the proper (normally system generated) headers and these contain the correct destinations. Or be sure all the queue managers have dead letter queues.
| MichaelBulla wrote: |
But I want the channel to start automatically, so there is no additional work needed, when the server is startet first time. Any ideas what could be the problem?
|
The problem is probably manually added messages on the xmitq.
Why does the channel have to start when the server starts? Configure it triggered as per the manual and it will start automatically when the first message needs to go across it, stopping and starting as needed.
It's the listener that needs to start with the queue manager, and under v6 this is achieved with a queue manager controlled object.
Simple.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MichaelBulla |
| Posted: Tue May 20, 2008 2:58 am Post subject: Re: Channel retrying on first start |
|
|
Apprentice
Joined: 27 Sep 2006
Posts: 31
Location: Hamburg/Germany
|
| Vitor wrote: |
| MichaelBulla wrote: |
| So I configure the MQ server and put some messages to a transmitQ |
Never write directly to the transmission queue. If you do, be very certain the messages have the proper (normally system generated) headers and these contain the correct destinations. Or be sure all the queue managers have dead letter queues.
|
Sorry, I think I worded wrong. I write to the transmitQ using a remoteQ that points to that transmitQ.
| Vitor wrote: |
| Why does the channel have to start when the server starts? Configure it triggered as per the manual and it will start automatically when the first message needs to go across it, stopping and starting as needed. |
There are Messages in the transmitQ, so the channel has to start.
Last edited by MichaelBulla on Tue May 20, 2008 3:06 am; edited 1 time in total |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 20, 2008 3:04 am Post subject: Re: Channel retrying on first start |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MichaelBulla wrote: |
| Vitor wrote: |
| MichaelBulla wrote: |
| So I configure the MQ server and put some messages to a transmitQ |
Never write directly to the transmission queue. If you do, be very certain the messages have the proper (normally system generated) headers and these contain the correct destinations. Or be sure all the queue managers have dead letter queues.
|
Sorry, I think I worded wrong. I write to the transmitQ using a remoteQ that points to that transmitQ. |
Ok, point taken. 
I still fail to see the point of lining stuff up on the xmitq (though I agree you're doing it correctly) or what this achieves. Do these messages flow back as some kind of confirmation that the server's been plugged in?
They're certainly unnecessary for the starting or stopping of the channel. On that I stand by my previous comments on configuration.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MichaelBulla |
| Posted: Tue May 20, 2008 3:42 am Post subject: |
|
|
Apprentice
Joined: 27 Sep 2006
Posts: 31
Location: Hamburg/Germany
|
We're using MQ to establish a reliable connection through a unreliable internet-connection between a store and the central. So I configure the central machine "online" because it's in use and the new store server offline, because it's configured at a place where I have no connection to the intranet. While configuring the new store-server I put in messages that are directed to the central and because theres no connection to central, they are kept in the transmitQ.
After the new server is connected to the intranet, it has connection to the intranet and should automatically connect to the central MQ server. But when I look at it the MQ Explorer the channel is all the time on retrying until I start it manually.
Maybe I got a hint. Is there a best practise to start and stop a MQ server? We do it by placing a start and a stop Script to /etc/init.d directory. Could that be a problem?
Bye Michael |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue May 20, 2008 3:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MichaelBulla wrote: |
| because theres no connection to central, they are kept in the transmitQ. |
I accept that if you put messages on an xmitq with the channel stopped, they will sit there. I still don't see what value these are adding, and do seriously suspect that they are in some way confusing the MCA & causing this retry behaviour.
I remain convinced that you'd be better served configuring the channel in the usual way to start on first message. Nothing you've said in your requirements has contradicted this.
Unless you can expand on this "channel must start when server starts". Channel's typically don't start when the server, or even the queue manager starts. They start when there's messages to send.
| MichaelBulla wrote: |
| After the new server is connected to the intranet, it has connection to the intranet and should automatically connect to the central MQ server. But when I look at it the MQ Explorer the channel is all the time on retrying until I start it manually. |
It should, and you should look in the queue manager logs to find out what error the MCA is reporting. I would not be surprised to discover it's complaining about an undeliverable persistant message it's inexplicably found in the xmitq.
| MichaelBulla wrote: |
Maybe I got a hint. Is there a best practise to start and stop a MQ server? We do it by placing a start and a stop Script to /etc/init.d directory. Could that be a problem?
|
I wouldn't have thought so. If the channel's in retry it's more likely the listener isn't running, and that's fixed using the object as I suggested.
If the MCA is not complaining about these rather pointless messages, my next guess would be it's in retry waiting for the listener to start. You stop it, you start it, by this time the listener has completed it's startup and the channel connects.
So patience could be a virtue.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue May 20, 2008 6:42 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Look at the tail of /var/mqm/qmgrs/<QMGRNAME>/errors/AMQERR01.LOG, there should be diagnostic messages describing why the channel initially goes into RETRY status.
_________________
Glenn |
|
| Back to top |
|
|
| MichaelBulla |
| Posted: Tue May 20, 2008 10:34 pm Post subject: |
|
|
Apprentice
Joined: 27 Sep 2006
Posts: 31
Location: Hamburg/Germany
|
| Quote: |
| I remain convinced that you'd be better served configuring the channel in the usual way to start on first message. |
I did so. But there are messages to send, so the channel should start on Queuemanager-start, shouldnt it?
Or did I confuse you by using "MQ server" instead of "Queuemanger"?
Maybe my understanding of how MQ works isnt right. In my understanding things should work like this:
QueuemanagerA (store server) has connection to intranet:
put message to remoteQ -> message is redirected to transmitQ -> channelstartup is triggert -> channel starts -> miracle happens -> message went from QueuemangerA to QueuemanagerB
QueuemanagerA (store server) has no connection to intranet:
put message to remoteQ -> message is redirected to transmitQ -> channelstartup is triggert -> cant start channel -> retry -> retry -> ... -> stop Queuemanager and Channels and everything -> time passes by -> connect to intranet -> start machine -> start Queuemanager -> channelstartup is triggert -> channel starts -> miracle happens -> message went from QueuemangerA to QueuemanagerB
Is that right, or is my understanding too naively?
While my investigations I found some problems, that could cause the error.
In /var/mqm/errors I found some error-messages: AMQ6209: An unexpected asynchronous signal. So it seems the Queuemanger didnt stop in a clean way. I assume the endmqm-Statement in /etc/init.d isnt finished when the server goes off.
Is there a way to make a blocking endmqm call?
Another thing: In /var/mqm/qmgrs/b0113/errors I found a strange behavior. When the Queuemanager is startet the logtimestamp is some about 11 a.m. At this time the Queuemanager is doing all the startup-stuff. At 11 a.m. it does also a try to connect the remote-machine and gets a TCP-error. After that the logtimestamp chenges to 8 a.m.
I think the server has while installation wrong SystemTime and gets updated by ntp when switched to intranet.
Can you tell me how the retry-timeout works? Could it be the channelstart fails at 11 a.m., so the channel is thinking "OK, restart at 11:05". But then the Systemtime is set back to 8:00 and so it waits for 3 hours?
Bye Michael |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed May 21, 2008 12:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| MichaelBulla wrote: |
| Or did I confuse you by using "MQ server" instead of "Queuemanger"? |
Perhaps a little. I blame my advanced age. 
| MichaelBulla wrote: |
Maybe my understanding of how MQ works isnt right.
...
Is that right, or is my understanding too naively? |
Simplistic but accurate, and I like the use of the word "miracle". 
Your root problem, as you've correctly stated, is the channel going into retry. It should not be necessary, or possible, to fix this by stopping or starting the channel. By the nature of "retry", the channel will "keep trying" to establish a connection with it's partner and will start running once this happens. Only a channel which is "stopped" needs to be started.
While my investigations I found some problems, that could cause the error.
| MichaelBulla wrote: |
| In /var/mqm/errors I found some error-messages: |
Now we're getting somewhere!
| MichaelBulla wrote: |
| Is there a way to make a blocking endmqm call? |
endmqm -w - check the documentation.
| MichaelBulla wrote: |
| Can you tell me how the retry-timeout works? Could it be the channelstart fails at 11 a.m., so the channel is thinking "OK, restart at 11:05". But then the Systemtime is set back to 8:00 and so it waits for 3 hours? |
Not personally (a passing IBMer with more information will pass shortly!) but it does sound plausible doesn't it? Certainly sounds like something you should take up with the box admin.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| MichaelBulla |
| Posted: Wed May 21, 2008 3:30 am Post subject: |
|
|
Apprentice
Joined: 27 Sep 2006
Posts: 31
Location: Hamburg/Germany
|
| OK, thanks for your guidance. I hope this will help next time. Otherwise I'll be back |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
