Sending Direct Messages
When sending a Direct message, client applications must consider the following factors:
- When using JCSMP, whether you want to send messages using a streaming or non-streaming mode. Refer to Streaming and Non-Streaming Sends in JCSMP.
- When using the Java RTO, C, or .NET APIs, whether you want to send messages using a blocking or non-blocking mode. Refer to Blocking and Non-blocking Network I/O.
- The number of messages to publish per send invocation. Refer to Sending One Message at a Time or Sending Multiple Messages at a Time.
- Whether you want to send messages that require a reply from the receiver. Refer to Publishing Messages that Request Replies.
Related Samples
For examples of how to publish and receive Direct messages, refer to the DirectPubSub
sample for the JCSMP, Java RTO, C, and .NET APIs, and the TopicSubscriber
and TopicPublisher
samples for the JavaScript and Node.js APIs.
Streaming and Non-Streaming Sends in JCSMP
JCSMP only supports a blocking network I/O model. However, when publishing messages, JCSMP can use a publish event handler that operates in either a streaming or a non-streaming mode. The mode used by the publish event handler is set when an XMLmessageProducer
is acquired.
To publish messages using JCSMP, a client must acquire an XMLMessageProducer
from the JCSMPSession
. Once it is acquired, the JCSMPSession
maintains a connection to the event broker and the application can then send messages.
XMLMessageProducer
can also be used to create Session‑dependent messages through the Producer interface (refer to Message Ownership).
The XMLMessageProducer
is in an “open” state until the close()
method is called on XMLMessageProducer
.
A client should cache an acquired instance, and close it only when it is no longer required. It is not efficient to acquire a new XMLMessageProducer
instance for every message sent.
To acquire an XMLMessageProducer
instance, call getMessageProducer(JCSMPStreamingPublishEventHandler callback)
and set the callback handler. When a non-null instance of the JCSMPStreamingPublishEventHandler
parameter is passed in, the send operation uses a JCSMPStreamingPublishEventHandler
to asynchronously get confirmation of message delivery failures using a callback mechanism.
Blocking and Non-blocking Network I/O
The Java RTO, C, and .NET APIs can use a blocking or non‑blocking network I/O model for send operations. This is controlled by the Send Blocking Session property. By default, this property is set to true
, so that a blocking mode is used.
When the Send Blocking Session property is set to false
, a non-blocking mode is used. If the OS/network cannot send the whole message without blocking the calling thread until more buffer space is available, the client application gets a WOULD_BLOCK
return code. When a WOULD_BLOCK
return code is received, the message is not sent and the client application must wait for a CAN_SEND
Session event, which indicates that the network is then ready for the send.
Sending One Message at a Time
To publish a single message per API call, call one of the send methods or functions listed below.
PubSub+ Messaging API | Use |
---|---|
JCSMP |
XMLMessageProducer.send(...) |
Java RTO |
SessionHandle.send(...) |
C |
solClient_session_sendMsg(...) |
.NET |
ISession.Send(...) |
JavaScript and Node.js |
solace.Session.send(...) |
When using JCSMP, and sending messages created from a Producer (that is Session‑dependent messages), ensure that the application:
- Does not send a
Message
instance created either in a previousJCSMPSession
or by anotherXMLMessageProducer
. Attempting to do this throws anIllegalArgumentException
. - Does not send the same message multiple times. Attempting to do this throws an
InvalidOperationException
. - Calls
close()
to close the producer when finished publishing. Any further access, such as sending messages, causes an exception to be raised.
Sending Multiple Messages at a Time
A group of Direct messages can be sent through a single API call. This allows messages to be sent in a batch or a vector. The messages to be sent are specified as an array; up to fifty messages can be sent through the call.
When batch sending messages, a Direct Delivery mode should be set for all of the messages (refer to Delivery Mode).
JCSMP
When using JCSMP, an array of {Message, Destination}
pairs (each represented by a JCSMPSendMultipleEntry
instance) must be passed in. This pairing allows messages to be sent to individual destinations. Each message must be an application‑owned message instance (that is, acquired from JCSMPFactory.createMessage(...)
).
JCSMP attempts to write all of the messages to the network at once and blocks until completion.
Java RTO, C, and .NET APIs
When using the Java RTO, C, or .NET APIs, an array of messages must be passed in. Unlike JCSMP, message destinations are not set through a send method; rather, they are set as a property for each message.
When a blocking mode is configured for the Session through the Session properties, the call blocks until all messages can be accepted by the messaging API. If a non‑blocking mode is configured, and the API cannot accept all messages to publish, SOLCLIENT_WOULD_BLOCK
is returned, and the number of messages that were accepted is returned in the in_out_howManySent
, numberOfMessagesWritten
, or messagesSent
parameter. The application can reattempt to send the messages that were not accepted or take another action.
PubSub+ Messaging API | Use |
---|---|
JCSMP |
XMLMessageProducer.sendMultiple(...) |
Java RTO |
SessionHandle.send(...) |
C |
solClient_session_sendMultipleMsg(...) |
.NET |
ISession.Send(...) |
JavaScript and Node.js |
Not supported |
Related Samples
For examples of how to publish a group of messages, refer to the PerfTest
sample for the appropriate messaging API.