How do I implement a GMD failure callback?
Article ID: KB0084841
Updated On:
| Products | Versions |
|---|---|
| TIBCO SmartSockets | - |
| Not Applicable | - |
Description
Resolution:
A GMD_FAILURE message notifies a publisher that a GMD message failed so that the publisher can take an appropriate action. By default, GMD outputs a warning, terminates GMD
for the failed message and continues.
If this default behavior is not sufficient for your application, create a process callback for the GMD_FAILURE message type to execute your own recovery procedures. The GMD_FAILURE message contains a copy of the failed message, the name of the receiver for whom it failed, the failure code for the error, and the time the original message was sent. The failed message is left in the publisher's GMD area, and it is up to the GMD_FAILURE process callback to either resend or delete the message. To resend the message, use TipcConnGmdMsgResend. To delete the message from the GMD area, use TipcConnGmdMsgDelete.
See the doumentation for TipcCbConnProcessGmdFailure for an example of an RTclient that uses a GMD failure callback. This example code creates a connection to RTserver, looks
up the callback that uses TipcCbConnProcessGmdFailure, destroys the default GMD callback and creates a new process callback for GMD_FAILURE messages.
Processing a GMD_FAILURE message is actually governed by two callbacks, one that processes the message on the RTclient side and one that deals with the RTserver
side. You may need to replace both of them, depending on you application's requirements. The callbacks that manages the RTclient processing of the failed GMD message is TipcCbConnProcessGmdFailure. This removes the message from the publisher's GMD area. TipcCbSrvProcessGmdFailure, which handles the RTserver, removes the message from the server.
A GMD_FAILURE message notifies a publisher that a GMD message failed so that the publisher can take an appropriate action. By default, GMD outputs a warning, terminates GMD
for the failed message and continues.
If this default behavior is not sufficient for your application, create a process callback for the GMD_FAILURE message type to execute your own recovery procedures. The GMD_FAILURE message contains a copy of the failed message, the name of the receiver for whom it failed, the failure code for the error, and the time the original message was sent. The failed message is left in the publisher's GMD area, and it is up to the GMD_FAILURE process callback to either resend or delete the message. To resend the message, use TipcConnGmdMsgResend. To delete the message from the GMD area, use TipcConnGmdMsgDelete.
See the doumentation for TipcCbConnProcessGmdFailure for an example of an RTclient that uses a GMD failure callback. This example code creates a connection to RTserver, looks
up the callback that uses TipcCbConnProcessGmdFailure, destroys the default GMD callback and creates a new process callback for GMD_FAILURE messages.
Processing a GMD_FAILURE message is actually governed by two callbacks, one that processes the message on the RTclient side and one that deals with the RTserver
side. You may need to replace both of them, depending on you application's requirements. The callbacks that manages the RTclient processing of the failed GMD message is TipcCbConnProcessGmdFailure. This removes the message from the publisher's GMD area. TipcCbSrvProcessGmdFailure, which handles the RTserver, removes the message from the server.
Issue/Introduction
How do I implement a GMD failure callback?
Feedback
Yes
No
Powered by
