10.26.0

ISessionSend(IMessage) Method

Sends a message over the session.

Definition

Namespace: SolaceSystems.Solclient.Messaging
Assembly: SolaceSystems.Solclient.Messaging (in SolaceSystems.Solclient.Messaging.dll) Version: 10.26.0
C#
ReturnCode Send(
	IMessage message
)

Parameters

message  IMessage
an IMessage instance

Return Value

ReturnCode
SOLCLIENT_OK if successful. Or SOLCLIENT_WOULD_BLOCK if the message cannot be accepted by the API immediately. The API signals its readiness to accept messages through a CanSend event type. Or SOLCLIENT_NOT_READY if the API is reconnecting.

Note: returning SOLCLIENT_OK means that the message has 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.

Special Buffering of Guaranteed Messages

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.

Exceptions

OperationErrorException Thrown when the Send operation fails. Possible sub-codes:
ObjectDisposedException Thrown when the session is already disposed (terminal state).
FatalErrorException Thrown when an unrecoverable error occurs.
ArgumentNullException Thrown if message is null.

See Also