Programming Issues for Message Consumers

This section describes two problems that consumers might need to manage:
the undetected loss of a connection, or the loss of a message for distributed
synchronous consumers.

Using the Client Runtime Ping Feature

Message Queue defines a connection factory attribute for a ping interval.
This attribute specifies the interval at which the client runtime should check
the client’s connection to the broker. The ping feature is especially
useful to Message Queue clients that exclusively receive messages and might
therefore not be aware
that the absence of messages is due to a connection failure. This feature
could also be useful to producers who don’t send messages frequently
and who would want notification that a connection they’re planning to
use is not available.

The connection factory attribute used to
specify this interval is called imqPingInterval. Its default value is 30 seconds. A value of -1 or 0, specifies
that the client runtime should not check the client connection.

Developers should set (or have the administrator set) ping intervals
that are slightly more frequent than they need to send or receive messages,
to allow time to recover the connection in case the ping discovers a connection
failure. Note also that the ping may not occur at the exact time specified
by the value you supply for interval; the underlying operating
system’s use of i/o buffers may affect the amount of time needed to
detect a connection failure and trigger an exception.

A failed ping operation results in a JMSException on
the subsequent method call that uses the connection. If an exception listener
is registered on the connection, it will be called when a ping operation fails.

Preventing Message Loss for Synchronous Consumers

It is always possible that a message can be lost for synchronous consumers
in a session using AUTO_ACKNOWLEDGE mode if the provider
fails. To prevent this possibility, you should either use a transacted session
or a session in CLIENT_ACKNOWLEDGE mode.

Synchronous Consumption in Distributed Applications

Because distributed applications involve greater processing time, such
an application might not behave as expected if it were run locally. For example,
calling the receiveNoWait method for a synchronous consumer
might return null even when there is a message available
to be retrieved.

If a client connects to the broker and immediately calls the receiveNoWait method, it is possible that the message queued for the consuming
client is in the process of being transmitted from the broker to the client.
The client runtime has no knowledge of what is on the broker, so when it sees
that there is no message available on the client’s internal queue, it
returns with a null, indicating no message.

You can avoid this problem by having your client do either of the following:

Use one of the synchronous receive methods that specifies
a timeout interval.

Use a queue browser to check the queue before calling the receiveNoWait method.