This is a collection of tips that will help you use Open MQ efficiently and effectively. This is an evolving section, but if you have questions about a part of the product you don't see mentioned here, drop us a line and we can help you directly, or we'll see about putting an answer into our queue for writing up a tip. To start with, we thought it would be useful to create a collection of tips, pulled out of the existing product documentation. As we hear from you, we'll be able to add more information that will help you succeed with Open MQ.
A client application running in a JVM needs enough memory to accommodate incoming messages as well as messages the client creates. If the client gets OutOfMemory errors, you will need to do some memory management. This may include taking one or more of the following steps:
- Increasing the heap size allotted to your application
- Breaking large messages into smaller parts and making sure they are concatenated properly.
- Compressing messages
For additional information and an example showing how you set and send a compressed message, go to Managing Memory and Resources in the MQ Developers Guide for Java Clients.
The Impact of Selector Use on Performance
How you use selectors can have a significant impact on application performance. It's hard to measure the impact exactly because it will vary with the complexity of selector expression and with the paths most often traveled as a result of user action. However, there are steps you can take to eliminate selectors or minimize their complexity. This might involve using multiple destinations to sort messages, having consumers share selectors, and making judicious use of selectors. For a detailed discussion, see the heading "Using Selectors Efficiently" in Client Design Considerations: Producers and Consumers in the Message Queue Developers Guide for Java Clients.
Using client threads effectively requires that you balance performance, throughput, and resource needs. To do this, you need to understand JMS restrictions on thread usage, what threads the Message Queue service allocates for itself, and the architecture of your applications. The Managing Client Threads section of the MQ Developer's Guide for Java Clients, provides additional information about JMS restrictions and Message Queue thread allocation. When it comes to the architecture of your applications however, you are the expert. If your application needs to run certain operations sequentially, using threads to execute these in parallel can lead to very undesirable results. Make sure that the threading strategy you use actually supports the way in which clients will use your application. For more details on this, browse to Managing Client Threads in the MQ Developers Guide to Java Clients.
Debugging: Using the Dead Message Queue
The Message Queue service provides a special queue, the dead message queue, where it will automatically store messages that cannot be delivered. You can set properties to specify whether a message should be sent to this queue if it cannot be delivered, whether information should be logged about a message that is destroyed or placed on this queue, and the kind of information you want to know about the dead message. You can examine messages on the dead message queue to determine why they could not be delivered and to determine the broker that produced the message and the broker that placed the message on the dead message queue. For more information, see the heading "Managing the Dead Message Queue" in the Managing Memory and Resources section of the MQ Developers Guide for Java Clients.
Detecting Connection Loss
Certain clients may need additional support to determine whether a connection has been lost. For example, clients who send messages infrequently may not be aware that a connection is no longer available. Or, clients who exclusively receive messages may not know that the absence of messages is due to connection failure. To help such clients, Message Queue allows you to define a ping interval (using a connection factory attribute). At the time specified by this interval the client runtime checks the client's connection to the broker. A failed connection will raise a JMSException and alert an exception listener to this condition. For more details, see Programming Issues for Message Consumers in the MQ Developers Guide for Java Clients.
In order to improve performance, you must understand how various factors affect performance. These include the message delivery mode used, the use of transactions, the acknowledgement mode set, and the use of durable or non durable subscriptions. Other factors, such as the use of selectors, message size, and message body type, also have an impact.
For further discussion about how to balance reliability and throughput, please have a look at Factors Affecting Performance in the MQ Developers Guide for Java Clients.
Connection event notifications allow a Message Queue Client to listen for closure and reconnection events and to take appropriate action based on the notification type and the connection state. The client can use these events to exit gracefully or to capture information that may be useful in resolving problems. The client listens for notification events using an event listener. The client runtime calls this listener when the following happens:
- The broker is about to close a connection due to a shutdown requested by the administrator.
- A connection is closed due to a broker error or administrative shutdown.
- The client runtime has reconnected to the same or a different broker.
- The client runtime has failed to reconnect to a broker.
For information about how to create an event listener see Connection Event Notification section of the MQ Developers Guide for Java Clients.
For information about how to enable auto-reconnect and how to handle exceptions in a variety of fail over situations, see the Auto Connection Fail over section in the MQ Developer's Guide for Java Clients.
Improving Performance by Using No Acknowledge Mode
No-acknowledge mode is a nonstandard extension to the JMS API. It allows consuming clients to forgo acknowledging the receipt of messages. This feature can be useful by non durable subscribers consuming non persistent messages, but it can be used by any consumer.
Using this feature improves performance by reducing protocol traffic and broker work involved in acknowledging messages. This feature can also improve performance for brokers dealing with clients who do not acknowledge messages and therefore waste broker memory resources.
Using this feature does raise the risk of message loss. For more information on how to create no-acknowledge sessions, see "Using No Acknowledge Mode" in the MQ Developers Guide for Java Clients.
We'll add more of these from time to time. Check back when you have time.