JMS learning three (Reliability of ActiveMQ messages)

ActiveMQ transaction session, response mode (transaction session and response mode are related), sending persistent messages, let's learn from two aspects: message acceptance confirmation and sending persistent messages.

1. Message reception confirmation

1. The jms message is considered to be successfully consumed only after it is confirmed. The successful consumption of a message usually includes three steps: (1), the client receives the message (2), the client processes the message (3), and the message is confirmed (that is, the client sends a confirmation message)

Whether it is a transactional or non-transactional session, the first and second steps are the same but the third step is different

2. In a transactional session, when a transaction is committed, confirmation occurs automatically, regardless of the response mode, this value can be written casually. (It is mentioned here that transactional sessions cannot be used in asynchronous message reception)

3. When a message is acknowledged in a non-transactional session depends on the acknowledgement model set in the session created. This parameter has three values:

(1) Session.AUTO_ACKNOWLEDGE: When the client side successfully returns from the receive method or from the onMessage(Message message) method, the session automatically confirms that the client receives the message.

(2) Session.CLIENT_ACKNOWLEDGE: The client confirms that the client receives the message by calling the acknowledge method. But it should be noted that in this reply mode, the acknowledgment is done at the session layer, and acknowledging a consumed message will automatically acknowledgment all other messages that have been consumed. For example, a consumer has consumed 10 messages, and then confirms that the 5th message has been consumed, then all 10 messages have been confirmed to be consumed.

The acknowledge() notification method is on the Message object

Synchronous reception, call the acknowledge() method to confirm:

consumer = session.createConsumer(queue); // Message consumer   
            Message message = consumer.receive(); // Receive 
            message.acknowledge() synchronously   ; // Message consumption confirmation notification

Asynchronous acceptance, call the acknowledge() method to confirm:

consumer.setMessageListener(new MessageListener() {  
                @Override  
                public void onMessage(Message message) {  
                    TextMessage textMessage = (TextMessage) message;  
                    try {  
                        String value = textMessage.getText();  
                        System.out.println("value: " + value);  
                        message.acknowledge(); // Message consumption confirmation notification   
                    } catch (JMSException e) {  
                        e.printStackTrace ();  
                    }  
                }  
            });

(3) Session.DUPS_ACKNOWLEDGE: It is not necessary to sign for receipt, and the message may be sent repeatedly. When retransmitting the message for the second time, the JmsDelivered in the message header will be set to true to indicate that the current message has been delivered once, and the client needs to control the repeated processing of the message.

summary:

1.Transacted transaction, the transaction is successfully committed, the message will be sent to mom
2.acknowledgeMode message confirmation mechanism
1),
session with transaction If the session has a transaction and the transaction is successfully committed, the message will be automatically signed. If the transaction is rolled back, the message will be delivered again.
2) Session
without transaction The sign-in method of session without transaction depends on the configuration of the session.
Activemq supports the following three modes:
Session.AUTO_ACKNOWLEDGE message is automatically signed
Session.CLIENT_ACKNOWLEDGE The client calls the acknowledge method to manually sign for
Session.DUPS_OK_ACKNOWLEDGE It is not necessary to sign for receipt, and the message may be sent repeatedly. When retransmitting the message for the second time,
the JmsDelivered in the message header will be set to true to indicate that the current message has been delivered once, and the client needs to control the repeated processing of the message.

2. Sending persistent messages

Sending persistent messages here is somewhat related to the persistence of messages, but they are not the same thing. Sending persistent messages means whether to persist the sent messages to disk or database, while message persistence refers to persisting messages. Whether it is to disk or database, one is whether to persist the message, and the other is how to persist the message.

What we want to write here is, of course, whether to persist the message or not. Activemq provides us with two options: persistence or non-persistence.

1. PERSISTENT: Instructs the JMS Provider to persist the message, and will persist the message to the disk to ensure that the message will not be lost due to the failure of the JMS provider and JMS Server.

2. NON_PERSISTENT: JMS Provider is not required to persist messages. If the JMS Server restarts, the message will be lost, and the consumer will also lose the message.

3. Message persistence settings:

MessageProducer producer = session.createProducer(queue);  
             // Whether the message is persistent, if not set, the default is persistent.  
            // producer.setDeliveryMode(DeliveryMode.PERSISTENT);  
             //For non-persistent messages, messages will not be persisted to disk. If the service is turned off and turned on again after sending, the message will be lost.  
             producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);

The persistence setting is very simple, right, but whether the message is persistent or not has a great impact on the performance of the application, and when the message volume is large, it is even more careful whether to persist the message.

JMS learning three (Reliability of ActiveMQ messages)

Guess you like