hi, u can handle the connectivity issues if u r putting or getting the msg under the syncpoint. Otherwise there r chances that ur message might get loss due to say some TCP/IP or communication error. Since when using the syncpoint, the client application explicitly when to commit or backout and u can use the return codes (MQRC and MQCC) to know the outcome of ur operations.
regards, Amit ---------------------------------------------------------------------------- --------------------- IBM certified MQ specialist > ---------- > From: Voges, P. (Pieter)[SMTP:[EMAIL PROTECTED]] > Reply To: MQSeries List > Sent: Wednesday, August 14, 2002 11:14 AM > To: [EMAIL PROTECTED] > Subject: C++ Foundation Classes > > Hi Everyone > > I got an interesting question from the development team. It comes down to > an application running on a Nt Box written in C++ using the mq-client > libraries connecting to a QMGR on a Unix AIX Box. The question is whether > or not there are build-in error handling in the C++ Foundation classes to > cater for loss of connectivity (either network or the QMGR going down). > Example - if you do a put to a queue on a qmgr which the client lost > connectivity to, will this be handled automatically or will he keep on > trying to put infinitaly regardless of the lost connectivity. (Will the > classes try to restore the connectivity and how?) > > Any info will be appreciated > > Pieter Voges > MQ Support > Nedcor Bank Limited > > > -----Original Message----- > From: Paul Clarke [ mailto:[EMAIL PROTECTED]] > Sent: 13 August 2002 02:11 > To: [EMAIL PROTECTED] > Subject: Re: Channel that always stays running > > > Can I add my two cents worth about Heartbeats. There have been one or two > slightly misleading comments about them which I think I ought to address. > > Heartbeats serve at least three purposes. > > 1/ They maintain contact with the receiver channel even when there are no > messages to send. This allows the receiver channel to ask the sender > channel to end (for example a STOP CHANNEL MODE(QUIESCE). So, if you > issued > a normal quiesce stop channel on a receiver and the channel wasn't moving > any messages it may take up to the heartbeat interval before the channel > actually ended. > > 2/ Since a heartbeat is only sent in relative inactivity the receiver > channel will free its resources when it gets one. For example it will free > > off any excessive message storage and close its queue cache. > > 3/ It allows the receiver to predict when data should arrive down the > socket. This is most pertinent to the current discussion of network > outage. > Without heartbeats a receiver channel can not predict when the next > message > will arrive from the sender since the sender has no clue either. However, > with heartbeats enabled the receiver knows that either it will receive a > heartbeat or a message within a known interval. Consequently the recveiver > > can issue a receiver with a timeout. If this receive does time out it > means > that something has gone seriously wrong. In an ideal world a network > outage > would cause the TCP/IP recv() call to return a nice return code however, > as > we all know, TCP/IP is notoriously bad at telling us about outages so this > > timeout is probably our best defence. I would still recommend that people > use KEEPALIVE though since there are some cases, such as SVRCONN channels, > > where we can't use a timeout. One last point about the timeout. The > timeout > value used will be > > if (Heartbeat Value < 1 minute) Timeout = Heartbeat * 2 > else Timeout = Heartbeat + 1 minute > > In other words we add a little contingency on the timeout for network > latency. > > Heop this helps, > > 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 > > 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
