WebSphere MQ Low Latency Messaging - Does it have a JMS (or JMS like) API?

Question

We are currently using IBM MQ via JMS, but seem to be pushing through more messages than it can handle - strangely, the problem seems to be intermittent.

The messages are prices and thus dont need to be guaranteed, just need to be sent quickly.

As IBM have a Low Latency product, I am wondering if that is perhaps the better solution - but it does not seem to have a JMS api, or at least not easily visible.

Anyone know if there is a JMS api into the Low Latency product, or if the "unique" API it does have is JMS-like...

Alternatively, pointers for MQ tuning would also be appreciated... :)

Answer 1

Definitely a low latency messaging product would be better suited to your problem, I am working on a project where we do something very similar using a low latency messaging product called LBM from 29West. It doesn't have a JMS api and I suspect most of the products in the low-latency space won't. There a large number of features that don't make sense in combination with these types of products (e.g. persistence, selectors, etc.). We found that writing our own simple api over the top of the messaging product to be fairly easy and gives use the flexibility to change products later and frees us from some of the bulk and verbosity of the JMS api.

Another option to consider would be JGroups.

29West have added JMS support to their messaging product line.

Answer 2

Regarding "pointers for MQ tuning", on the SupportPacs page there are performance evaluations per platform with specific recommendations. Scroll down to the SupportPacs named MP* and look for the appropriate version and platform. A variety of scenarios are tested with large and small messages, persistent and non-persistent, variations on numbers of getter and putters, etc.

Answer 3

As a former developer for the LLM product I can say that it does or at least did. See below for an excerpt I took from the publicly available infocenter for version 2.6

That said, from what I recall the whole point of MQ was guaranteed delivery. There is a time and a place for this but it comes at a cost in terms of latency and bandwidth.

LLM has a different purpose fundamentally; it has reliable delivery: that is if it fails to deliver you will simply know that it failed to deliver. Recoverability of these messages is only limited by how much you are willing to keep cached or recall from disk and thus how long you are willing to tolerate waiting for recovery while holding up your process.. In your case, you might not care to recover. Whether LLM is right for you or not I can't speculate. What I can say is that from my point of view as a past developer and later as a client, I found little to no resemblance between the two, and the performance of LLM for this kind of application blew MQ out of the water completely. I also never used the java/jms side very much and was focused on C/C++ so take this with a grain of salt. I just knew that it did it and where to look in google.

http://www-01.ibm.com/support/knowledgecenter/SSQPD3_2.6.0/com.ibm.wllm.doc/api/javadoc/messaging/com/ibm/llm/jms/package-summary.html

Package com.ibm.llm.jms Description

Implement the provider specific public classes for the LLM JMS client.

Most of the interfaces used in JMS are defined by the common JMS interfaces. However, the JMS specification does not include the classes and interfaces needed to configure the JMS client.

See The JMS API documentation for information about the JMS classes and methods.

Introduction

The LLM JMS client provides a Java Message Service (JMS) interface to LLM. Using the JMS interface to LLM allows for a common interface with other messaging providers, and speeds application development by allowing developers to use interfaces they are familiar with. Using the JMS interface works best for applications which use generic messaging function where the settings can be centrally administered. This includes many traditional client applications. The LLM JMS client does not work as well where the application is dependent on LLM specific functions or which require significant application interaction with LLM. While there is some latency added by using the JMS interface, it still provides very low latency and high throughput messaging.

The LLM JMS client supports most LLM client function, but does not support the server function of running within a tier, or being a load balance transmitter.

LLM is based on doing direct producer to consumer messaging. JMS is normally implemented using a message server and JMS function which requires the message server is not available when using the LLM JMS client. This includes all point-to-point messaging (queues) as well a the recover function. The LLM JMS client is designed to run in a JSE environment and does not support application server extensions or XA transactions.

How the LLM JMS client implements JMS

The LLM JMS client implements each of the fundamental JMS objects with an implementation class which is not exposed externally. The subclasses of these objects are implemented using the same implementation class. This means that there are only two administered objects, ConnectionFactory and Destination. An LLM defined ConnectionFactory can be cast to TopicConnectionFactory and QueueConnectionFactory, and an LLM defined Destination can be cast to Topic and Queue. The same is true for Connection, Session, MessageProducer, and MessageConsumer. The Destination object from one provider must be used with a Connection by the same provider. However, it is possible to send a message produced by one JMS provider to another JMS provider. Sending a message created by another JMS provider is not as efficient as sending a message created by the LLM JMS client, but this function is provided to make it easy for an application to bridge from one provider to another.

The LLM JMS client does not implement the point to point messaging model (queues), but all JMS objects can be created.

The LLM JMS client requires a JVM of at least Java 5.

The LLM JMS client defines all six message type objects (Message, BytesMessage, MapMessage, ObjectMessage, StreamMessage, and TextMessage). When sending a message from JMS to JMS, the JMS header indicates the type of message. If the JMS header is missing (which is common when sending a message from a non-JMS producer) the LLM JMS client tries to deduce the type of the message from the content. Normally the message will appear as a BytesMessage, but if the message start with a UTF-8 BOM or appears to be XML it will be interpreted as a TextMessage. TextMessages are assumed to be coded in UTF-8......