>Ruzi, its the lack of a heartbeat coming back to the RCVR that tells the >RCVR there is a network problem, allowing the RCVR to go Inactive.
>Paul, is the below an accurate scenario where Heartbeat and AdoptMCA work >together? Peter, I'll add my comments..... >A receiver must be in an Inactive state to reestablish communications after >a network failure. This is true if you don't use AdoptMCA >You can get the RCVR in this state by manually stopping and starting it >(blah), or letting the Heartbeat Interval pass. Correct although a contingency is added to the heartbeat interval to allow for network latency - by default this is 1 minute. So with default settings (a heartbeat of 5 minutes) if you pulled out the network cable on a running channel I would expect the receiver channel to end with a timeout failure after 6 minutes. >Once that interval passes, the RCVR will go into the Inactive state on it's own. >It's at this point that the SNDR's request for a connection will finally work. >i.e. it finally caught the RCVR in an Inactive state. Correct >If the SNDR would never try to reestablish communications until after the >Heartbeat Interval put the RCVR in an Inactive state, there would be no need >for AdoptMCA. I suppose this is true although generally after a failure a sender channle will immediately try tro to reconnect just in case it was a network glitch. >But I would bet that usually more messages are coming to the >sender before that has a chance to happen, and in this case AdoptMCA kicks >in and lets the connection reestablish itself before Heartbeat does its >thing. Exactly, this is the reason for AdoptMCA. Usually the sender channel notices a network outage first because a TCP send() is proactive. You get a bad return code from a send() call far quicker than a bad return code from a recv() call. So the sender reconnects and without AdoptMCA set it will fail with a channel not available message because it thinks there is already a receiver channel running. Hope this is clear if not we'll have to make this a special discussion group at the next conference. Cheers, P. Paul G Clarke WebSphere MQ Development IBM Hursley Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
