SessionProperties.GuaranteedDeliveryReconnectFailAction Enumeration

Solclient

previous page next page

Solclient

SessionPropertiesGuaranteedDeliveryReconnectFailAction Enumeration

version: 7.2.1.27

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

Namespace: SolaceSystems.Solclient.Messaging
Assembly: SolaceSystems.Solclient.Messaging (in SolaceSystems.Solclient.Messaging.dll) Version: 7.2.1.27 (7.2.1.27)

Syntax

C++

Copy

public enum GuaranteedDeliveryReconnectFailAction

Public Enumeration GuaranteedDeliveryReconnectFailAction

public enum class GuaranteedDeliveryReconnectFailAction

Members

	Member name	Value	Description
	AUTO_RETRY	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	1	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.

Member name

Value

Description

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.

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

Reference

SolaceSystems.Solclient.Messaging Namespace

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to use and copy the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

UNLESS STATED ELSEWHERE BETWEEN YOU AND SOLACE SYSTEMS, INC., THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Send comments on this topic to [email protected]

previous page start next page