Friday, March 28, 2014

JMS Message Selectors and OSB

JMS Topics are a good way to keep publishing messages and multiple subscribers can fetch messages based on their criteria. How we define the criteria is one of the main decision points that should be considered while defining the message structure and headers of the message. In one of the implementations done recently there was a requirement where consumers wanted to filter the messages based on a status, that was part of the body .So instead of reading all messages and parsing the status ,they were looking for a way to easily filter the messages.
As per the JMS spec ::
A JMS message selector allows a client to specify, by header field references and property references, the messages it is interested in. Only messages whose header and property values match the selector are delivered. What it means for a message not to be delivered depends on the Message Consumer being used.
Message selectors cannot reference message body values.
A message selector matches a message if the selector evaluates to true when the message's header field values and property values are substituted for their corresponding identifiers in the selector.
A message selector is a String whose syntax is based on a subset of the SQL92 conditional expression syntax. If the value of a message selector is an empty string, the value is treated as a null and indicates that there is no message selector for the message consumer.
A property value may duplicate a value in a message's body, or it may not. Although JMS does not define a policy for what should or should not be made a property, application developers should note that JMS providers will likely handle data in a message's body more efficiently than data in a message's properties. For best performance, applications should use message properties only when they need to customize a message's header. The primary reason for doing this is to support customized message selection
Weblogic customized the message selector for weblogic JMS.
JMS_BEA_SELECT is a built-in function in WebLogic JMS SQL syntax. You specify the syntax type, which must be set to xpath (XML Path Language) and an XPath expression.
    Eg:- JMS_BEA_SELECT('xpath', '/message/status/text()') = ‘REQUEST_SUBMITTED’
But from OSB point of view, the message selector goes by strict JMS spec and the custom Message selector function - JMS_BEA_SELECT is not supported as it is designed to be more generic and needs to communicate with JMS Topics from different vendors. So the only supported options will be to have custom message headers defined on the message and consumers filtering on them, even it means duplicating the fields in header and body of the message.

Wednesday, March 19, 2014

Weblogic JMS Topic does not support durable subscriptions-workaround


One of our service consumers where facing issues with durable subscription. They were able to successfully connect as durable subscribers in Single node topic, but they started issues once they started connecting to clustered environments where the topic where configured as Uniform Distributed Topic.

Error Snippet
-------------
weblogic.jms.common.JMSException: [JMSClientExceptions:055030]This topic does not support durable subscriptions
                at weblogic.jms.client.JMSSession.createDurableSubscriber(JMSSession.java:2482)
                at weblogic.jms.client.JMSSession.createDurableSubscriber(JMSSession.java:2460)
                at weblogic.jms.client.WLSessionImpl.createDurableSubscriber(WLSessionImpl.java:1204)
                at com.artesia.video.flip.ArtesiaConnectionInitializer.run(ArtesiaConnectionInitializer.java:168)
 
Topic configuration
--------------------------
GeoDownloadTopic
Uniform Distributed Topic
jms/Topic/GeoTestTopic
GEOJMSTopic_SD
  GEOJMSServer_1, GEOJMSServer_2, GEOJMSServer_3, GEOJMSServer_4

To use durable subscription you will need to use JNDI of individual node Topic.

Eg: -  GEOJMSServer_1@jms.Topic.GeoDownloadTopic


How to get the JNDI name of each node
  • Click the Servers node to expand it and expose the names of the servers currently being administered through the console.
  • Click the name of the server whose JNDI tree you want to view.
  • Scroll down to the bottom of the Configuration pane, and Click the "View JNDI Tree" link.
  • The JNDI tree will appear in a new browser window. You can click on an individual object name to view information about its bind name and hash code.