Java messaging service summary

  jms, mq

First, the role of message middleware

Message-Oriented Middleware (MOM).
The use of message middleware generally has two functions: one is decoupling and the other is asynchronous (it plays the role of cutting peaks and filling valleys)

Second, the basic specification of JMS

1. Message Delivery Model

  • Point-to-point model (queue-based model, if there are multiple consumers, then these consumers take turns consuming messages to achieve load balancing)

  • Publish subscription model
    Topic-based publish/subscribe model is popular, which is usually the main model, plus point-to-point model to achieve load balancing for producers/consumers.

2. Message receiving model

  • Push technology: the message server actively pushes messages to message consumers (JMS Pub/Sub uses push technology)

  • Pull technology: message consumers regularly fetch messages from the message server (JMS recipients can push or pull messages depending on whether it u ses asynchronous onMessage callback or synchronous receive method)

The synchronous receive mode is the pull mode, the consumer takes the initiative to fetch the message from the message server, and the asynchronous listener mode is the push mode.

Instances of synchronous receive:

// Create the sender and send the message
QueueSender qSender = qSession.createSender(requestQ);
qSender.send(msg);
// Wait to see if the loan request was accepted or declined
String filter = "JMSCorrelationID = '" + msg.getJMSMessageID() + "'";
QueueReceiver qReceiver = qSession.createReceiver(responseQ, filter);
TextMessage tmsg = (TextMessage)qReceiver.receive(30000);
if (tmsg == null) {
   System.out.println("Lender not responding");
} else {
    System.out.println("Loan request was " + tmsg.getText());
}

3. Basic concepts

Basic concepts: message producer, message consumer, message, destination /topic/ route

(1) api specification for 1)JMS1.X

图片描述

(2) api specification for 2)JMS2

图片描述

4. Message format

A message can be divided into three parts: a message Head, an Attribute, and a Payload (message body).

(1) Message header

This part is usually structured data and provides metadata related to the message.

  • Message unique identifier

  • Destination

  • Delivery method (persistent/non-persistent)

  • Message receiving time

  • Message expiration time

  • Message priority

  • Whether to resend, etc.

(2) message attributes

Advanced features for JMS, as well as storing some application-specific attributes or additional features provided by JMS vendors.

  • A. advanced functions: groupId/groupSeq, grouping aggregation of messages

  • B, apply the attributes you added: such as username, etc.

  • C. additional functional attributes of special manufacturers

(3) Message body

Generally, there can be structured and unstructured ones. JMS has more detailed definitions, including Text, Object, Bytes, Stream, Map and other formats. However, most of them are in byte[] format. You can choose your own custom serialization method.

III. Message Distribution

1. Message Selector

Using a message selector on the destination and using message attributes and message headers (data in the message body cannot be used) as criteria for conditional expressions, messages are filtered before the destination (queue/topic) is distributed to consumers. (rabbitmq has an expression filtering method based on routing key to select which topic messages to receive)

2, consumer control or producer control

(1)MessageFilter, the consumer controls the message filtering and decides what message it wants to accept

  • Messages are filtered before the destination is distributed to consumers.

  • The advantage of using MessageFitler is that it is more scalable. Assuming that a CustType is added to the PLATINUM level, it is only necessary to add a corresponding message consumer.

(2)Multiple Destination, multi-purpose mode, producer control message distribution

  • Messages are filtered before being sent to destinations and distributed to different messages at different destinations.

  • If Multiple Destination is used, a queue is added to save PLATINUM, and a class is added to listen to this new queue.

  • The advantage of MultipleDestination is that the producer controls the classification of message filtering, which is not easy to make mistakes, but has a little poor scalability. MessageFilter has good scalability, but is easy to make mistakes.

3, failed to filter out the message how to deal with

1) Publish/Subscribe Model:

These messages will not be delivered to the subscriber, whether persistent or non-persistent

2) Point-to-point model:

  • All messages not selected by the consumer are invisible to the consumer.

  • Confirm that all messages produced by the sender or publisher have their respective validity periods associated with them. The default is never expired , which means that if a message is filtered out and not delivered to the consumer, it will permanently reside in the queue and can be resolved by setting the survival time.

  • Some manufacturers have proposed the concept of Dead Letter Queue (DLQ) or Deadline Message Queue (DMQ) to process messages that are considered unable to be transmitted.

In the simplest case, the messaging system places all messages that cannot be delivered into the DMQ, while the application is responsible for monitoring its contents. Administrative events can also be supported, and applications can be notified when messages are placed in DMQ.

For rabbitmq, there is a dead letter mechanism (when a message becomes a dead letter in a queue, it can be republished to another Exchange, which is DLX).

IV. Basis of Message Reliability

1. Message saving and forwarding mechanism

  • A guaranteed delivery mechanism ensures that the intended consumer will eventually receive the message even if a malfunction occurs.

  • When the consumer fails, the message is stored in the persistent medium, and after waiting for the consumer to recover, the message is taken out from the persistent medium and forwarded to the consumer

2、DeliveryMode

public interface DeliveryMode {
    /** This is the lowest-overhead delivery mode because it does not require 
      * that the message be logged to stable storage. The level of JMS provider
      * failure that causes a <CODE>NON_PERSISTENT</CODE> message to be lost is 
      * not defined.
      *
      * <P>A JMS provider must deliver a <CODE>NON_PERSISTENT</CODE> message 
      * with an 
      * at-most-once guarantee. This means that it may lose the message, but it 
      * must not deliver it twice.
      */

    static final int NON_PERSISTENT = 1;

    /** This delivery mode instructs the JMS provider to log the message to stable 
      * storage as part of the client's send operation. Only a hard media 
      * failure should cause a <CODE>PERSISTENT</CODE> message to be lost.
      */

    static final int PERSISTENT = 2;
}

Message defaults to PERSISTENT mode.
This place is a confusing place in JMS. In essence, it is marked by the deliveryMode attribute of the message header.
There can be two settings:

(1) for message producers

When sending a message, whether the setting is persistent or not;

msg.setJMSDeliveryMode(Message.DEFAULT_DELIVERY_MODE);

The default is persistent mode.

(2) for news consumers

It is to set the transmission mode before receiving the message. For example, the method of providing durableSubscriber for topic.

public interface TopicSession extends javax.jms.Session {
    javax.jms.Topic createTopic(java.lang.String s) throws javax.jms.JMSException;

    javax.jms.TopicSubscriber createSubscriber(javax.jms.Topic topic) throws javax.jms.JMSException;

    javax.jms.TopicSubscriber createSubscriber(javax.jms.Topic topic, java.lang.String s, boolean b) throws javax.jms.JMSException;

    javax.jms.TopicSubscriber createDurableSubscriber(javax.jms.Topic topic, java.lang.String s) throws javax.jms.JMSException;

    javax.jms.TopicSubscriber createDurableSubscriber(javax.jms.Topic topic, java.lang.String s, java.lang.String s1, boolean b) throws javax.jms.JMSException;

    javax.jms.TopicPublisher createPublisher(javax.jms.Topic topic) throws javax.jms.JMSException;

    javax.jms.TemporaryTopic createTemporaryTopic() throws javax.jms.JMSException;

    void unsubscribe(java.lang.String s) throws javax.jms.JMSException;
}

3. Lost reconnection

When the network connection between the client and the server is lost, the JMS provider must reestablish the connection as much as possible. If the JMS provider cannot reconnect automatically, when the client calls a method that can cause network traffic, the provider must throw an exception to notify the client of the situation. JMS provides an ExceptionListener interface to capture lost connections (which can be reconnected during capture) and notify the client of this situation. Unlike MessageListener, MessageListener is bound to a session.

V. Message Confirmation Mechanism

Generally, it is determined automatically and manually.

1. When a message producer sends a message

TopicPublisher.publish and QueueSender.send methods are synchronized and are responsible for sending messages while blocking until an acknowledgement is received from the message server. Once an acknowledgement is received, the execution thread resumes and returns to the method, believing that the message was sent successfully. The underlying validation is not visible to the client programming model. If a fault condition occurs during this operation, an exception will be thrown and the message will be deemed not to have been transmitted (note that resending refers to the resending of the consumer server to the consumer).

2. When the message consumer receives the message

If the session is in AUTO_ACKNOWLEDGE mode, the JMS provider’s client runtime environment must automatically send a confirmation message to the server when each consumer gets the message. If the server does not receive this confirmation message, it will assume that the message has not been transmitted and may attempt to retransmit it.

3. When the message server sends and receives messages

(1) the server receives the message from the producer and sends a confirmation to the producer

A confirmation message is sent from the server to the producer, which means that the server has received the message and has assumed the responsibility of transmitting it. From the JMS server’s point of view, the acknowledgement sent to the producer is not directly related to message delivery. Logically, they are two independent steps.

  • A. For persistent messages, the server writes the message to disk and then notifies the producer that the message has been received.

  • B for non-persistent messages, it means that the server can notify the sender immediately after receiving the message and store the message in memory. If the subject of the messa ge has no subscribers, the message may be discarded depending on the manufacturer.

(2) Confirm when the message consumer receives it

  • A. for durable subscribers
    Until the message server receives confirmation from all intended recipients of the message, the message server will not consider that the message has been delivered. To obtain this information, every consumer must know very well which client has received each message and which has not. Once the message server delivers the message to all known subscribers and has received acknowledgements from the subscribers respectively, the message will be deleted from persistent storage. If the subscription is persistent and the subscriber is not currently connected, the message server will save the message until the subscriber becomes available or the message expires. This is true even for non-persistent news. In other words, if the message consumer is set to a persistent subscription, whether the message producer sets the message to be persistent or not, it will always be saved and forwarded when the consumer is not present.

  • B. for non-persistent messages
    After the message server has confirmed the message to the sender and before the message server has the opportunity to write the message to disk on behalf of unconnected persistent subscribers, there may be a time window between the two. If JMS fails within this time window, the message may be lost.

  • C, if persistent messages are used
    A provider may fail, but it will gracefully return to normal. Since messages are stored in persistent storage, they are not lost and will be delivered to consumers when the provider starts again. If it is a point-to-point queue, they can be guaranteed to be delivered. If it is a publish subscription, it can be guaranteed to be delivered only if the consumer’s subscription is persistent. The delivery behavior of non-persistent subscriptions varies from provider to provider.

Six, the news transaction mechanism

1, producers to submit the news of the transaction

  • Before the producer commit, the JMS provider will not start sending messages to its consumers, even if it has received all the messages from the sender.

  • When sending messages, if the commit method is not called after the sending method completes normally, the JMS provider deletes the messages from the queue and the messages are not delivered to the consumer.

2, consumer consumption news affairs

  • Messages are delivered to the recipients as soon as possible, but they are kept by JMS providers until the recipients publish a commit on the session object. If a failure occurs or a rollback is called, the providers will attempt to retransmit these messages, in which case these messages will be set as retransmission flags.

  • When receiving a message, if the commit method is not called after the normal completion of the receiving message method, the message will be marked as undelivered, and the JMS provider will retransmit these messages to the consumer and mark JMSRedelivered as true, indicating that it has tried to process these messages before.