JMS specifications are built upon the concepts of Topics and Queues, but Apache Pulsar™ has only a general concept of Topics that can model both of those two domains.
In Pulsar there is no concept of a queue: undefined treats Pulsar topics as queues when queue-related JMS API are in use. There is no strict, cluster wide, verification that you are accessing a JMS Queue using the Topic API or vice versa.
In JMS a Topic is written by many Producers and read by many Consumers that share one or many Subscriptions. Subscriptions may be Durable or Non-Durable (meaning the client position not retained on restart), and Shared or Non-Shared determining whether the same message may be received and processed by more than one consumer.
JMS Concept | Pulsar Concept |
---|---|
Topic | Persistent topic |
Consumer | Exclusive non-durable subscription with random name ( UUID ) |
DurableConsumer | Exclusive durable subscription with the given name + clientId |
SharedConsumer | Shared non-durable subscription with the given name + clientId |
SharedDurableConsumer | Shared durable subscription with the given name + clientId |
DurableSubscriber | Exclusive durable subscription with the given name + clientId |
For SharedConsumer and SharedDurableConsumer , set jms.topicSharedSubscriptionType to Key_Shared to use the Key_Shared subscription type.
In JMS a Queue is written by many Producers but only one Consumer eventually processes each message.
In order to emulate that behavior, the first time you create a consumer over a queue, undefined creates a durable subscription named jms-queue at the beginning (initial position = Earliest) of the Pulsar topic.
Every access to the queue passes through the shared subscription and guarantees that only one consumer receives and processes each message.
JMS Concept | Pulsar Concept |
---|---|
Queue | Persistent topic |
Consumer | Shared durable subscription with name jms-queue |
QueueBrowser | Pulsar Reader for the topic, beginning from the next message on jms-queue subscription |
In order to implement QueueBrowser , undefined uses the Pulsar Reader API, starting from the next message available on the jms-queue subscription. In order to peek at the next message undefined uses the Pulsar Admin API peekMessages .
undefined doesn't deal with schema, and it treats every message as a raw array of bytes, interpreting the content of the message according to the JMS API that is used, and to a special JMSPulsarMessageType property.
JMS specs require that, on the consumer side, you receive a message of the same type sent by the producer:
- TextMessage
- BytesMessage
- StreamMessage
- MapMessage
- ObjectMessage
When the JMS consumer receives a message that has not been produced by undefined itself and lacks the JMSPulsarMessageType property, it converts the message to a BytesMessage .
Pulsar message keys and JMSXGroupID
The special JMSXGroupID property is defined in the JMS specs as a way to group messages and enable routing to the same destination.
undefined maps that property to the message key in Pulsar, ensuring that JMSXGroupID is used as the routing key.
Next
- Pulsar Jms Quickstart Sa: Create a simple command line Java JMS client that connects to a local Pulsar installation.
- Pulsar Jms Quickstart Astra: Create a simple command line Java JMS client that connects to an Astra Streaming instance.
- Pulsar Jms Install: Install undefined in your own JMS project.Pulsar Jms Implementation: Understand key implementation details for undefined.
- Pulsar Jms Faq: Frequently asked questions about undefined.
- Pulsar Jms Reference: undefined configuration reference.
- *undefined Github repo*