Until a JMS message has been acknowledged, it is not considered to be successfully consumed. The successful consumption of a message ordinarily takes place in three stages.
1. The client receives the message.
2. The client processes the message.
3. The message is acknowledged. Acknowledgment is initiated either by the JMS provider or by the client, depending on the session acknowledgment mode.
- ACKNOWLEDGMENT- by specifying various levels of control over message acknowledgment
- PERSISTENCE - by specifying that messages are persistent, that they must not be lost in the event of a provider failure
- PRIORITY - by setting various priority levels for messages, which can affect the order in which the messages are delivered
- EXPIRATION - by specifying an expiration time for messages, so that they will not be delivered if they are obsolete
- TEMPORARY DESTINATION - by creating temporary destinations that last only for the duration of the connection in which they are created
TopicSession topicSession = topicConnection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE);
Message acknowledgment in non-transacted sessions depends on the value specified as the second argument of the createQueueSession() or createTopicSession() method. The three possible argument values are:
- Session.AUTO_ACKNOWLEDGE. The session automatically acknowledges a client’s receipt of a message either when the client has successfully returned from a call to receive or when the MessageListener it has called to process the message returns successfully. A synchronous receive in an AUTO_ACKNOWLEDGE session is the one exception to the rule that message consumption is a three-stage process. In this case, the receipt and acknowledgment take place in one step, followed by the processing of the message.
- Session.CLIENT_ACKNOWLEDGE. A client acknowledges a message by calling the message’s acknowledge method. In this mode, acknowledgment takes place on the session level: Acknowledging a consumed message automatically acknowledges the receipt of all messages that have been consumed by its session. For example, if a message consumer consumes ten messages and then acknowledges the fifth message delivered, all ten messages are acknowledged.
- Session.DUPS_OK_ACKNOWLEDGE. This option instructs the session to lazily acknowledge the delivery of messages. This is likely to result in the delivery of some duplicate messages if the JMS provider fails, so it should be used only by consumers that can tolerate duplicate messages. (If it redelivers a message, the JMS provider must set the value of the JMSRedelivered message header to true.) This option can reduce session overhead by minimizing the work the session does to prevent duplicates.
Session.commit(). If a transaction is rolled back - Session.rollback(), all consumed messages are redelivered.
With a Topic, the provider retains unacknowledged messages for a terminated
TopicSession with a durable TopicSubscriber. Unacknowledged messages for a nondurable TopicSubscriber are dropped when the session is closed.
Session.recover - what does it do?Session.recover() method to stop a non-transacted session and restart it with its first unacknowledged message. In effect, the session’s series of delivered messages is reset to the point after its last acknowledged message. The messages it now delivers may be different from those that were originally delivered, if messages have expired or higher-priority messages have arrived. For a nondurable TopicSubscriber, the provider may drop unacknowledged messages when its session is recovered. Read on in Part 2 about Message Persistence, Expiration and Temporary Destinations.
0 Response to “JMS - Ensuring Reliability | Part - 1”