ISessionSend(IMessage, Int32, Int32, Int32) Method

ReturnCode Send(
	IMessage[] messages,
	int offset,
	int length,
	out int messagesSent
)

Parameters

messages  IMessage

Array of IMessage instances. If duplicate IMessage entries were used in the messages array, they must notbe Guaranteed messages, in this case an ArgumentOutOfRangeException is thrown

offset  Int32

Offset into the array of first message to send.

length  Int32

Number of messages to send, from offset.

messagesSent  Int32

Returns the number of messages that were sent.

Return Value

Note: returning SOLCLIENT_OK means that the messages have been successfully copied to the underlying transport which does not guarantee successful delivery to the Solace appliance. In the case of persistent or non-persistent messages, the application will receive a subsequent Acknowledgement event for all messages (persistent and non-persistent) successfully delivered to the Solace appliance. For guaranteed(persistent or non-persistent) messages which cannot be accepted by the Solace appliance (quota, permission or other delivery problems), a RejectedMessageError event will be generated.

Guaranteed messages (MessageDeliveryMode.Persistent or MessageDeliveryMode.NonPersistent) are assured by the protocol between the client and the Solace message-router. To make developers' task easier, guaranteed messages are queued for delivery in many instances:

• While transport (TCP) flow controlled.
• While message-router flow controlled.
• While sessions are connecting or reconnecting.
• While sessions are disconnected or down.

The SDK will buffer up to a publishers window size (ADPublishWindowSize ) of guaranteed messages before ISession.Send() will either block (when SendBlocking is enabled) or return SOLCLIENT_WOULD_BLOCK (on active sessions) or return SOLCLIENT_NOT_READY (on disconnected or reconnecting sessions).

For the most part this is desired behavior. Transient sessions failures do not require special handling in applications. When ReconnectRetries is non-zero, the underlying transport will automatically reconnect and the publishing application does not need to concern itself with special handling for the transient reconnecting state.

Special consideration is required for applications using host lists. 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