Guaranteed Delivery Reconnect Fail Actions

Defines the valid set of actions the API will take if it is unable to reconnect guaranteed delivery after a session reconnect. More...

Macros
#define	SOLCLIENT_SESSION_PROP_GD_RECONNECT_FAIL_ACTION_AUTO_RETRY   ("GD_RECONNECT_FAIL_ACTION_AUTO_RETRY")
	Clear the publisher state and reconnect the publisher flow. More...
#define	SOLCLIENT_SESSION_PROP_GD_RECONNECT_FAIL_ACTION_DISCONNECT   ("GD_RECONNECT_FAIL_ACTION_DISCONNECT")
	Disconnect the session, even if SOLCLIENT_SESSION_PROP_RECONNECT_RETRIES is configured to a non-zero value. More...

Detailed Description

Defines the valid set of actions the API will take if it is unable to reconnect guaranteed delivery after a session reconnect.

This will occur when a host-list is used, such as for disaster recovery. After session reconnect to the next router in the host-list the guaranteed delivery reconnect will not succeed as guaranteed delivery state is only preserved between a high-availability pair.

Macro Definition Documentation

#define SOLCLIENT_SESSION_PROP_GD_RECONNECT_FAIL_ACTION_AUTO_RETRY   ("GD_RECONNECT_FAIL_ACTION_AUTO_RETRY")

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.

#define SOLCLIENT_SESSION_PROP_GD_RECONNECT_FAIL_ACTION_DISCONNECT   ("GD_RECONNECT_FAIL_ACTION_DISCONNECT")

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 considerations are required for SOLCLIENT_SESSION_PROP_GD_RECONNECT_FAIL_ACTION_DISCONNECT:

• When a reconnect occurs on a different host, an application publishing guaranteed messages will receive the SOLCLIENT_SESSION_EVENT_DOWN_ERROR event with the SOLCLIENT_SUBCODE_UNKNOWN_FLOW_NAME 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 solClient_session_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 SOLCLIENT_SESSION_EVENT_DOWN_ERROR 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 solClient_session_connect() on the session that has gone down, this session should instead be destroyed and a new session created to establish a new connection.