Introduction to JMS and ActiveMQ (2) _ JMS

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436004549-0.jpg "title =" slide 7.JPG" alt = "181144337.jpg"/>

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143600F54-1.jpg "title =" slide 8.JPG" alt = "181211455.jpg"/>

JMSAPI can be divided into three main parts: public API, queue API, and topic API.

In JMSAPI, ConnectionFactory and Destination can be both managed objects created by the JMS provider and obtained from the provider using JNDI, or can be directly created dynamically;

Other interfaces are created through the factory method. For example, sessions can be created through Connection;

Generally, the message producer and consumer only create one Connection), but can create multiple Session sessions );

The Session stores the transaction unit used for message sending.

You can use Session to create Message, MessageProducer, and MessageConsumer.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436003107-2.jpg "title =" slide 9.JPG" alt = "181244742.jpg"/>

Messages can be divided into three parts: Message Header, attribute, and payload.

Messages are divided into automatic message headers and developer message headers.

Automatically assigned message headers:

1) JMSDestination: The Message destination.

2) JMSDeliveryMode: message transmission mode. The default mode is persistent.

3) JMSMessageID, the Message ID.

4) JMSTimestamp: the time when the JMS provider receives the message.

5) JMSExpiration: Message expiration time. The default value is 0, indicating that the message will never expire.

6) Whether JMSRedelivered is a resend message.

7) JMSPriority, 0 ~ Level 4 is a common priority, and level 5 ~ Level 9 indicates the priority of an emergency.

The message header assigned by the developer:

1) JMSReplyTo: the destination of the Response Message sent after receiving the message.

2) JMSCorrelationID, a specific ID associated with the message. In most cases, it is used to record the ID of the previous message when a response message is sent after receiving the message.

3) JMSType: Message type.

Attribute:

Similar to a message header, it is added by a developer and supports String, Int, Boolean, Double, Float, Byte, Long, Short, and Object types. It can be used for message selection;

Payload, that is, the content of the actually transmitted message.

Based on the load type to be carried, JMS defines six message interfaces:

Message, excluding the payload;

TextMessage, carrying a String as the payload;

ObjectMessage, carrying a Java object that can be serialized as a payload;

BytesMessage carries a group of original byte streams;

StreamMessage, carrying a Java raw data type stream;

MapMessage, which carries a set of key-value pairs as the payload.

Message persistence, Which is set through JMSDeliveryMode. In Persistent mode, a message is persistently stored on the server until the consumer receives the message. Therefore, the message can be successfully sent once, in non-persistent mode, messages can be sent at most once, but messages cannot be received successfully.

650) this. width = 650; "src =" http://img1.51cto.com/attachment/201309/181317579.jpg "title =" slide 10.JPG" alt = "181317579.jpg"/>

For the use of Apis related to message producers, we will describe the queue and topic respectively.

Under the queue:

Create a queueConnection through the connection factory class provided by ActiveMQ.

QueueConnection calls the start method to truly establish a persistent connection with the message server.

Call the createQueueSession method of queueConnectoin to create a session unit for message-related operations.

Call the createQueue, createSender, and createMessage methods of the queueSession to create queues, senders, and messages respectively.

Finally, call the send method of queueSender to send a message. Message sending is a synchronous operation. In the send method, the thread is blocked until confirmation from the Message Server is received.

In the topic, the calling methods of each interface in the message production process are similar to those in the queue, but some interfaces related to the topic are used. Therefore, for message production, you can use APIs in public APIs.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436004018-4.jpg "title =" slide 11.JPG" alt = "181346160.jpg"/>

Use APIs in the public API to Implement Message producers. interfaces such as Connection, Session, Destination, and MessageProducer in the public API are used.

When creating destination, call the createTopic method and createQueue method to create the topic and queue respectively.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436005013-5.jpg "title =" slide 12.JPG" alt = "181411646.jpg"/>

We also discuss the use of Apis related to message consumers in queue and topic.

In the queue, call the createReceiver method of the queueSession to create the receiver.

Call the receive method of queueReceiver to receive messages. In the receive method, the thread is blocked until the message is received. You can also set the maximum latency when calling the receive method. If no message is received within this time period, the receive method will return directly.

Under the topic, call the createSubscriber method of topicSession to create a subscriber.

In addition, you need to implement the MessageListener interface to implement the message listener and override the onMessage method of the listener. Register the listener to the subscriber through setMessageListener of topicSubscriber. When the Message Server pushes a message to topicSubscriber, topicSubscriber calls the onMessage method of the listener to process the message.

650) this. width = 650; "src =" http://img1.51cto.com/attachment/201309/181440686.jpg "title =" slide 13.JPG" alt = "181440686.jpg"/>

Use APIs in the public API to Implement Message consumers.

For queues and topics, except for different methods when creating destination, the consumer in the queue blocks the thread from actively receiving messages through the receive method during message reception, comsumer under a topic is a message pushed by setting a listener.

650) this. width = 650; "src =" http://img1.51cto.com/attachment/201309/181517760.jpg "title =" slide 14.JPG" alt = "181517760.jpg"/>

The difference between a persistent subscriber and a common subscriber is that when a common subscriber is not connected, the messages sent will be lost and the messages will not be received after the connection, for persistent subscribers, messages sent when they are not connected will be saved, and the messages will be normally received after the connection.

Creating a persistent subscriber is different from creating a regular subscriber. One is to set ClientID in the connection, the other is to call the createDurableSubscriber method to create a persistent subscriber and set the subscriber name when creating a subscriber. The messageservice uses ClientID and subscriber name as the unique identifier of a persistent subscriber. When the connection is not established, the messageservice keeps a copy of the message and sends the message to the persistent subscriber.

To completely disable a persistent subscriber so that the Message Server no longer retains a copy of the message, you need to call the unsubscribe method.

A persistent subscriber can receive messages normally regardless of whether the subscriber is connected or not.

The disadvantage of a persistent subscriber is that if the subscriber has never been connected, the message will be continuously saved, resulting in Storage pressure.

Therefore, whether to choose a persistent subscriber depends on the specific application scenario. If you want to ensure that the subscriber can still receive all messages when the connection is lost, use a persistent subscriber, if only the subscriber needs to receive messages during connection and certain message loss is allowed, the common subscriber is used.

650) this. width = 650; "src =" http://img1.51cto.com/attachment/201309/181543737.jpg "title =" slide 15.JPG" alt = "181543737.jpg"/>

Messages in the queue can only be consumed by one consumer. If you view messages in the queue but do not consume messages, you can use QueueBrowser.

Call the getEnumeration method to obtain all messages in the current queue in the order of message receipt.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143600HB-9.jpg "title =" slide 16.JPG" alt = "181611827.jpg"/>

Consumers sometimes need to process messages that meet specific conditions. A feasible solution is to add a condition judgment before processing a message. messages that do not meet the conditions are not processed, however, a problem with this solution is that the message has been received by the consumer but will not be processed, resulting in a waste of network bandwidth, in addition, messages that are not processed cannot be received by other consumers who may process these messages.

We can solve the above problem through the message selector. The message selector can be used to filter messages and only receive messages meeting specific requirements.

The conditions that can be added to the Message selector include the message header and message attributes. The message headers that can be used as selection criteria include JMSDeliveryMode, JMSPriority, JMSMessageID, JMSTimestamp, JMSCorrelationID, and JMSType. For example, messages with a higher weight can be selected. You can set business attributes in the message attributes so that you can select a message that meets specific business needs.

The basic expression of the message selector is composed of identifiers, comparison operators, and constants, for example, JMSPriority> 5, that is, messages whose choice is greater than 5.

Multiple basic expressions Can be composed of and or, for example, JMSPriority> 5 AND between = 'delete ', that is, messages with a weight of five and a business operation type of "Delete" are selected.

The message selector is set when a consumer is created as follows.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/143600HY-10.jpg "title =" slide 17.JPG" alt = "181634269.jpg"/>

For persistent messages, the message server will confirm the messages to ensure that the messages are successfully sent.

Message validation mechanisms include AUTO_ACKNOWLEDGE, DUPS_ OK _ACKNOWLEDGE, and CLIENT_ACKNOWLEDGE,

The message confirmation mechanism can be specified when the session is created.

AUTO_ACKNOWLEDGE is automatically confirmed by the Message Server.

Message sending and receiving are two asynchronous processes. Therefore, we discuss the message validation of the AUTO mechanism in these two processes respectively.

When a message is sent:

1) when the producer sends a message, the producer blocking thread waits for the Message Server to receive confirmation of the message.

2) The Message Server persists the message after receiving the message.

3) after the persistence is successful, the message server sends a confirmation notification to the producer.

4) After receiving the confirmation notification, the producer returns it from the sending method.

When receiving a message:

5) the consumer receives messages.

6) The Consumer sends a confirmation notification.

7) The Message Server deletes messages from the storage.

Unlike AUTO, DUPS_ OK _ACKNOWLEDGE is a delay and batch confirmation mechanism for a single message. One advantage of this mechanism is that it can reduce the system overhead caused by single message confirmation, however, one problem is that a message may be sent more than twice to the same destination. Therefore, it is applicable to scenarios where messages can be repeatedly received.

CLIENT_ACKNOWLEDGE is confirmed by the consumer by calling the acknowledge method of the message. If the consumer uses the CLIENT mechanism and calls the acknowledge method, unconfirmed messages sent between the last confirmation will be confirmed.

INDIVIDUAL_ACKNOWLEDGE is also confirmed by the consumer by calling the acknowledge method of the message, but unlike the CLIENT mechanism, each message needs to call the acknowledge Method for confirmation.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436001A8-11.jpg "title =" slide 18.JPG" alt = "181702304.jpg"/>

Message transactions can ensure that:

If there is only one message producer or only one message consumer in a session, the transaction ensures that all the messages are sent to the server or not to the Message consumer, transactions ensure that they receive all messages or do not receive any messages.

If there are both message producers and consumers in a session, the transaction will ensure that all messages are sent, received, or not sent or received.

When creating a session, you can set whether to use transactions.

After multiple operations, call commit () to submit. When an exception occurs, roll back by calling rollback.

650) this. width = 650; "src =" http://www.bkjia.com/uploads/allimg/131228/1436002622-12.jpg "title =" slide 19.JPG" alt = "181744622.jpg"/>

Spring provides support for JMS. On the client, you can configure the connection, producer, and consumer through Spring.

The DefaultMessageListenerContainer provided by spring can be used to set message listening, and the JmsTemplate provided by spring can be used to send and receive messages.

This article is from the "Learning document" blog, please be sure to keep this source http://zephiruswt.blog.51cto.com/5193151/1303872