|0||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.|
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.