JMS 2.0: Shared-Durable-Consumer on Topic vs Asynchronous-Consumer on Queue; Ref. Official GlassFish 4.0 docs/javaee-tutorial Java EE 7

Question

Ref: Official GlassFish 4.0 docs/javaee-tutorial Java EE 7

Firstly, let us start with the destination-type of: topic. As per GlassFish 4.0 tutorial, section “46.4 Writing High Performance and Scalable JMS Applications”:

This section describes how to use the JMS API to write applications that can handle high volumes of messages robustly.

In the subsection “46.4.2 Using Shared Durable Subscriptions”:

The SharedDurableSubscriberExample.java client shows how to use shared durable subscriptions. It shows how shared durable subscriptions combine the advantages of durable subscriptions (the subscription remains active when the client is not) with those of shared consumers (the message load can be divided among multiple clients).

When we run this example as per “46.4.2.1 To Run the ShareDurableSubscriberExample and Producer Clients”, it gives us the same effect/functionality as previous example on destination-type of queue: if we follow “46.2.6.2 To Run the AsynchConsumer and Producer Clients”, points 5 onwards – and modify it slightly using 2 consumer terminal-windows and 1 producer terminal-window.

Yes, section “45.2.2.2 Publish/Subscribe Messaging Style” does mention:

The JMS API relaxes this requirement to some extent by allowing applications to create durable subscriptions, which receive messages sent while the consumers are not active. Durable subscriptions provide the flexibility and reliability of queues but still allow clients to send messages to many recipients.

.. and anyway section “46.4 Writing High Performance and Scalable ..” examples are queue style – one message per consumer:

Each message added to the topic subscription is received by only one consumer, similarly to the way in which each message added to a queue is received by only one consumer.

What is the precise technical answer for: why, in this example, the use of Shared-Durable-Consumer on Topic is supposed to be, and mentioned under, “High Performance and Scalable JMS Application” vs. use of Asynchronous-Consumer on Queue?

Answer 1

I was wonderign about the same issue, so I found out the following link. I understand that John Ament gave you the right reponse, maybe it was just too short to get a full understand.

Basically, when you create a topic you are assuming that only the subscribed consumers will receive its messages. However processing such a message may requires a heavy processing; in such a cases you can create a shared topic using as much threads as you want.

Why not use a queue? The answer is quite simple, if you use a queue only one consumer will be able to handle such a message.

In order to clarify I will give you an example. Let's say a federal court publishes thousand of sentences every day and you have three distinct applications that depends on it.

Application A just copy the sentences to a database. Application B parse the sentence and try to find out all relation between people around all previously saved sentences. Application C parse the sentence and try to find out all relation between companies around all previously saved sentences.

You could use a Topic for the sentences, where Application A, B and C would be subscribed. However it easy to see that Application A can process the message very quicly while Application B and C may take some time. An available solution would consist of create a shared subscription for application B and another one to application C, so multiple threads could act on each of them simultaneouly...

...Of course there are other solutions, you could for example use a unshared topic (i.e. a regular one) and post all received messages on a ArrayBlockingQueue that would be handled by a pool of threads some time later; howecer in such a decision the developer would be the one to worry about queue handling.

Hope this can help.

Answer 2

The idea is that you can have multiple readers on a subscription. This allows you to read more messages faster, assuming you have threads available.

Answer 3

JMS Queue :

1. queued messages are persisted
2. each message is guaranteed to be delivered once-and-only-once, even no consumer running when the messages are sent.

JMS Shared Subscription :

1. subscription could have zero to many consumers
2. if messages sent when there is no subscriber (durable or not), message will never be received.