API Threading
The APIs use a context to organize communications between a client application and a PubSub+ event broker. A context acts as a container for configuring one or more sessions and handling session-related events, and it encapsulates threads that drive network I/O and message delivery notification for the sessions. Message delivery and reception can also require application-provided threads.
Threading When Publishing Messages
The client application provides the processing thread required to publish Guaranteed messages to a destination on the event broker.
When the event broker successfully receives Guaranteed messages, it returns acknowledgments to the API. It does not return acknowledgments for Direct messages. (The exception to this is publishing Direct messages using JCSMP's non-streaming publishing mode.)
The context uses a processing thread to read the acknowledgment from the event broker. It then parses the windowed acknowledgment, enqueues separate acknowledgments for each message (identified by a message ID), then dispatches them to an application callback.
PubSub+ Messaging API for Java RTO, C, and .NET
In the PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API, a context uses a single thread to read the windowed acknowledgment that the event broker sends for the received Guaranteed messages and parse them. Unlike JCSMP, acknowledgments from the event broker are not placed in a notification queue; rather, the same thread is used for notification and dispatching the queued acknowledgments to an application callback.
The figure below shows the application thread used to send Guaranteed messages and the context thread used to handle windowed message acknowledgments from the event broker.
Publishing Guaranteed Messages Using the PubSub+ C API and PubSub+ .NET API
PubSub+ Messaging API for JavaScript and Node.js
The PubSub+ JavaScript API and PubSub+ Node.js API are single-threaded including notification and dispatching the acknowledgments to application event listeners.
Threading When Receiving Messages
When receiving published messages, the context uses a processing thread to read messages off the socket, parse them, and then, depending on the PubSub+ Messaging API and whether a synchronous or asynchronous mode is used, enqueue the messages for delivery or consumption, or perform customer notification and message dispatch.
Client applications can use one of the following modes to receive published messages:
- Asynchronous
Client applications can use PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API to receive published messages asynchronously. For more information, see Receiving Messages Asynchronously.
- Synchronous
Client applications can also use JCSMP to receive published messages synchronously. For more information, see Receiving Messages Synchronously.
Receiving Messages Asynchronously
A client application can use PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API to receive messages in an asynchronous manner. That is, when messages are available, they are automatically sent ("pushed") to a message callback or message delegate interface from the API to the client application.
When receiving messages asynchronously, the context uses a processing thread for consumer notification and dispatching the queued messages to consumers; all callbacks from the API to the application, such as message receive callbacks, event callbacks, and timer callbacks, run from a context thread.
When a client application is using asynchronous transacted sessions, messages are dispatched from one or more transacted session dispatcher threads. Either a single transacted session dispatcher thread that is bound to the context (this is the default) or separate transacted session dispatcher threads that are bound to each transacted session can be used. For more information, see Using Local Transactions.
PubSub+ Messaging API for Java RTO, C, and .NET
Contexts used by the PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API asynchronously receive messages in a way similar to that used by JCSMP when the MESSAGE_CALLBACK_ON_REACTOR session property is enabled. The PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API only use one processing thread for the context. This thread reads messages off the socket, parses them, and then performs consumer notification and dispatches the messages to consuming applications.
For the PubSub+ C API, the required context thread can optionally be supplied by the client application instead of relying on the internal API thread. For more information, see PubSub+ C API Best Practices.
Receiving Messages Asynchronously With PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API
PubSub+ Messaging API for JavaScript and Node.js
The PubSub+ JavaScript API and PubSub+ Node.js API are single-threaded including asynchronous receiving of messages through application message event listeners.
Receiving Messages Synchronously
When receiving messages in a synchronous manner, the client application uses explicit receive calls to retrieve messages from the message queues that the API uses for each consumer. When receiving messages synchronously, the client application provides the threads that “pull” the enqueued messages from the API.
PubSub+ Messaging API for Java RTO, C, and .NET
The PubSub+ Java RTO API, PubSub+ C API, and PubSub+ .NET API can only receive messages asynchronously in a non-transacted session. However, these APIs can receive messages synchronously within a transacted session.
PubSub+ Messaging API for JavaScript and Node.js
Receiving messages synchronously is not supported for the PubSub+ JavaScript API and PubSub+ Node.js API.