Handling GMD Failures

A synchronous error such as TipcConnFlush returning FALSE and setting the global SmartSockets error number to T_ERR_EOF or T_ERR_FAILURE_DETECTED. These errors are easy to detect and handle, such as call TipcConnDestroy and then TipcConnCreateClient.

An asynchronous GMD_FAILURE error such as a delivery timeout. The causes of these errors are very application-specific.

As discussed in GMD_FAILURE, recovery from GMD_FAILURE messages is very application-specific, and SmartSockets cannot perform it on its own. The GMD_FAILURE message notifies the process that there is a problem, and the process can take whatever user-defined action is necessary. SmartSockets by default outputs a warning, terminates GMD for the failed message, and continues.

GMD_FAILURE Messages

When GMD fails asynchronously, a GMD_FAILURE message is created internally by SmartSockets and TipcConnMsgProcess is called to process the message and thus notify the sender that there has been a GMD failure. GMD programs can create connection process callbacks for the GMD_FAILURE message type to execute their own recovery procedures. The failed message is left in the connection GMD area, and it is up to the GMD_FAILURE process callbacks to delete the message (and thus terminate GMD for that message) or resend the message.

a MSG message field containing the message sent by this process where GMD failed

a STR string field containing the name of the receiving process where GMD failed (actually the value of the receiving process’s Unique_Subject option)

an INT4 integer field containing a SmartSockets error number describing how GMD failed

a REAL8 numeric field containing the wall clock time the failed message was originally sent

Delivery Timeout Failures

As described in GMD_FAILURE, the only type of GMD_FAILURE message produced for non-RTclient/non-RTserver GMD is a delivery timeout failure: the third field of a GMD_FAILURE message is T_ERR_GMD_SENDER_TIMEOUT. Connections automatically check for delivery timeouts whenever data is read from the connection with TipcConnRead, or the connection is checked to see if data can be read with TipcConnCheck. Thus it is important to use TipcConnRead and TipcConnCheck frequently enough and with timeout parameters that are not larger than the connection delivery timeout property or the delivery timeout of an individual message.

Default Processing of GMD_FAILURE Messages

All connections by default have a process callback for GMD_FAILURE messages that use TipcCbConnProcessGmdFailure as the callback function. TipcCbConnProcessGmdFailure outputs a warning and deletes the message from the connection GMD area.

TipcCbConnProcessGmdFailure is intended as a sample callback that is designed only to warn the user that guaranteed delivery of a message has failed. More sophisticated applications should destroy the callback that uses TipcCbConnProcessGmdFailure and create their own process callbacks for GMD_FAILURE messages to perform actions such as user-defined recovery procedures. See the reference page for TipcCbConnProcessGmdFailure in the TIBCO SmartSockets Application Programming Interface reference for full details on this callback.

When a GMD_FAILURE message is processed by a sender, one of two actions is typically performed:

the sender process does not want to resend the message, and thus uses TipcConnGmdMsgDelete to terminate GMD for the message

the sender process does want to resend the message, and thus takes some kind of user-defined action to correct the problem and then uses TipcConnGmdMsgResend to resend the message

Resending a Message

if (!TipcConnGmdMsgResend(conn, msg)) { 
  /* error */ 
}

TipcConnGmdMsgResend usually is only used from a GMD_FAILURE connection process callback.

Deleting a Message

A single message can be deleted from the connection GMD area with TipcConnGmdMsgDelete. For example:

if (!TipcConnGmdMsgDelete(conn, msg)) { 
  /* error */ 
}

TipcConnGmdMsgDelete usually is only used from a GMD_FAILURE connection process callback.