Using Individual Message Acknowledgements
This section covers various advanced topics, which will typically only apply to special situations or advanced users. The section is divided into the following topics:
Using Individual Message Acknowledgements
The JMS specification defines three acknowledge modes, which cover many
typical application requirements. However, the JMS does not specify that
messages can be acknowledged individually. When using CLIENT_ACKNOWLEDGE,
all messages received by a consumer will be acknowledged regardless of
which message the acknowledge method is invoked on.
JMS allows messages to be acknowledged individually using the
JMQSession's
INDIVIDUAL_ACKNOWLEDGE flag. This example shows how to create
manager applications for queues and durable subscribers, which can remove
(acknowledge) individual messages.
The JMS specification allows you to specify message expiry, i.e. the time
after which the JMS provider should discard the message. However, it is not
possible to specify message start time using standard API's. The ability to
delay the delivery of a message without sacrificing reliability is however
an important feature when building message applications. This example shows
how to use the JMS_jbmq_Delay message property.
The Novell exteNd Messaging Platform's JMS supports automatic compression of messages by using the
JMS_jbmq_Compress boolean property. If JMS_jbmq_Compress
is set to true, the message will automatically be compressed before it is
transmitted to the server, and it will automatically be de-compressed before
it is handed over to a message consumer. Compression is supported for all message
types (bytes, map, object, stream, SOAP, text, XML, and file). Message compression
can significantly improve performance when using slow network connections or large
messages.
In general, JMS has strict rules about serializing callbacks to consumers to deliver messages. If a session has multiple consumers, only one onMessage method at a time will be called. This is a great benefit to the application developer because he or she does not have to be concerned about make onMessage thread-safe.
For performance reasons, an advanced application may desire to consume messages concurrently. For this a separate optional construct called a connection consumer is defined in JMS. This sample program shows how to create a ServerSessionPool, and setup a Connection Consumer for concurrent processing of subscription messages.
The exception listener is a powerful concept, which allows JMS client applications to discover error that happen asynchronously. As an example, an exception listener is notified when the connection to the JMS server breaks or when messages could not be delivered to a message listener. This example shows different uses of exception listeners.
Certain applications may desire to run the JMS server in-process to speed up delivery or consumption from message-intense clients, or to reduce the number of processes in a system. This example show how to use the JMQMessageService API to run JMS in-process.
This example illustrates how to access a JMS destination from within a servlet. Although a servlet uses the same programming model as any other JMS client application, it typically requires more configuration because it is deployed as a WAR. The servlet initialization must roughly set the same environment as the jmqrun client application runner.
This example illustrates how to use the JMSAdmin manageable
object to obtain runtime properties from a JMS server. The JMS properties
are mostly various counters for number of messages processed,
etc. Monitoring these properties can be used to assess the health of the
JMS server.
This example illustrates how to use the JMQSOAPMessage to
easily exchange SOAP message on a JMS transport using the SOAP with Attachments
API for Java (SAAJ). The example also illustrates how to use the SAAJ provider
from the Novell exteNd Web Services SDK.