Dark Mode

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 ConceptPulsar Concept
TopicPersistent topic
ConsumerExclusive non-durable subscription with random name ( UUID )
DurableConsumerExclusive durable subscription with the given name + clientId
SharedConsumerShared non-durable subscription with the given name + clientId
SharedDurableConsumerShared durable subscription with the given name + clientId
DurableSubscriberExclusive 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 ConceptPulsar Concept
QueuePersistent topic
ConsumerShared durable subscription with name jms-queue
QueueBrowserPulsar 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.

  • 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*