JMS 2.0 with WSO2 ESB (Part II)
JMS Shared Topic Subscription
In earlier versions of JMS, if multiple consumers are connected to a topic subscription all the messages comes to that particular topic will be forwarded to each of the consumer in every subscription.
With the introduction of JMS 2.0 there is new type of subscription that can be used, its Shared Topic Subscription. Messages that comes to a shared topic subscription will not be broadcasted, it will only be forwarded to one single subscriber client.
Following sample explains how you can set and observe Shard Topic Subscription on WSO2 ESB JMS inbound endpoint. I am using HornetQ for the testing purpose.
- Configuring WSO2 ESB for HornetQ with JMS 2.0
Please refer here [1]
2. Configuring WSO2 ESB for the Sample
- Create two sequences as follows,
- Create two inbound endpoints using following configurations.
These configurations will create two shared topic subscribing inbound endpoints on the same topic subscription. There for these two inbounds will share the message consumption on that subscription. Inbound Ep 1 will forward its consumed messages to sequence 1 and inbound EP 2 will forward to sequence 2.
3. Now run the TopicPublisher.java which will publish 5 messages to the HornetQ topic.
Observation
Total number of 5 messages will be shared between the two inbound endpoints, on WSO2 ESB console you will be able to observe that.
** If you are using durable shared topic subscription on WSO2 ESB JMS inbound endpoint, you have to set “true” for transport.jms.SubscriptionDurable parameter and don’t need to set the transport.jms.DurableSubscriberClientID parameter. Even if you set a client ID it will be ignored in durable shared topic subscription.
JMS Message Delivery Count
In JMS messages that are consumed by clients, there is a property defined by the JMS-API called JMSXDeliveryCount. The purpose of this is to maintain a counter to indicate the number of times a message has been (re)delivered to a particular JMS consumer client. Even Though this property existed in the versions prior to JMS 2.0, setting it was not mandatory for the JMS providers. But from JMS 2.0 it has been mentioned as a mandatory property.
Following sample explains how you can access this property inside WSO2 ESB Synapse configuration and use it inside mediation flow.
- Configuring WSO2 ESB for HornetQ with JMS 2.0
Please refer here [1]
2. Configuring WSO2 ESB for the Sample
- Create the following message store
- Create the following sequence
- Create the following inbound endpoint
Above configuration will create an JMS inbound endpoint that consumes messages from a Queue and inject those in the configured sequence. This sequence will use the JMS message delivery count value to mediate the message. It will put a copy of each message that has delivery count more than one so that those messages can be examined later.
3. Now run the SOAPPublisher.java to publish a message to the JMS queue.
Observation
A log will be printed on WSO2 ESB console regarding the delivery count of the message and if the count is more than one, copy of those message will be sent to the configured message store.
** Under these conditions you won’t generally observe redelivered messages. But you can set this sample with ActiveMQ (with JMS 1.1) in transaction mode and when a transaction fails redelivery of messages can be observed.
References
[1] https://docs.google.com/document/d/1UJ_cObagC8d3HFyH17hxf7R0SOI_7blBMyQMS9M83vg/edit?usp=sharing
