10.26.0

SessionPropertiesGuaranteedDeliveryReconnectFailAction Enumeration

Specify the behavior when the CCSMP API is unable to reconnect guaranteed delivery after reconnecting the session. This may occur if the session is configured with a host list where each Solace router in the host list is unaware of state of the previous router. It can also occur if the time to reconnect to the same router exceeds the publisher flow timeout on the router. GdReconnectFailAction

Definition

Namespace: SolaceSystems.Solclient.Messaging
Assembly: SolaceSystems.Solclient.Messaging (in SolaceSystems.Solclient.Messaging.dll) Version: 10.26.0
C#
public enum GuaranteedDeliveryReconnectFailAction

Members

AUTO_RETRY0 Clear the publisher state and reconnect the publisher flow. Then republish all unacknowledged messages, this may cause duplication. The API then continues the reconnect process as usual.
DISCONNECT1 Disconnect the session, even if SOLCLIENT_SESSION_PROP_RECONNECT_RETRIES is configured to a non-zero value. This is the legacy behavior. If the application attempts to manually reconnect the session, it is also responsible for unacknowledged messages. If the application chooses to resend those messages, there may be duplication. If the application chooses not to resend those messages there may be message loss.

Special consideration is required for applications setting GdReconnectFailAction to DISCONNECT. When a reconnect occurs on a different host, an application publishing guaranteed messages will receive the DownError event with the UnknownFlowName sub-code. When this occurs, any queued messages are flushed. Messages published after this event has been raised will be queued then sent after a subsequent connect initiated by the application by calling Connect.

Multi-threaded applications should be aware that some, but not necessarily all, messages published on one thread may be flushed due to failed reconnect, as messages published after the DownError event are not flushed. If the application chooses to republish some or all unacknowledged messages after the send queue has been flushed there is a possibility that these old, republished messages may be queued after newly published messages.

If the possibility of old messages after new messages is a concern, it is recommended that instead of calling Connect on the session that has gone down, this session should instead be destroyed and a new session created to establish a new connection.

See Also