Re: C++ Foundation Classes

[GIES, STEVE]

Title: C++ Foundation Classes

Pieter -

No, if connectively is lost sometime between the internal MQCONN call and the MQPUT call, you will get back an appropriate error message - 2002? - but the classes will not attempt to redrive the put call.

 

- Steve

-----Original Message-----
From: Voges, P. (Pieter) [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 13, 2002 10:45 PM
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