Docker learning method steps to build ActiveMQ message service

Preface

ActiveMQ is the most popular and powerful open source message bus produced by Apache. ActiveMQ is a JMS Provider implementation that fully supports JMS1.1 and J2EE 1.4 specifications. Although the JMS specification has been introduced for a long time, JMS still plays a special role in today's J2EE applications.

In production projects, message middleware is often needed to communicate between distributed systems. It has a series of features such as low coupling, reliable delivery, broadcasting, flow control, and eventual consistency. This article mainly introduces the concepts and installation instructions of ActiveMQ. Later, it will focus on SpringBoot integration to implement the spike message queue.

concept

JMS Message Mode

Point-to-point or queue mode

Contains three roles: message queue (Queue), sender (Sender), and receiver (Receiver). Each message is sent to a specific queue and the receiver gets the message from the queue. Queues hold messages until they are consumed or time out.

• Each message has only one consumer, that is, once consumed, the message is no longer in the message queue.
• There is no time dependency between the sender and the receiver, that is, when the sender sends a message, whether the receiver is running or not, it will not affect the message being sent to the queue
• After successfully receiving the message, the receiver needs to reply to the queue successfully.

Pub/Sub

Contains three roles: Topic, Publisher, and Subscriber. Multiple publishers send messages to a Topic, and the system delivers these messages to multiple subscribers.

• Each message can have multiple consumers
• There is a time dependency between publishers and subscribers. For a subscriber to a topic, it must create a subscriber before it can consume the publisher's messages.
• In order to consume messages, the subscriber must remain running.

To relax such strict time dependencies, JMS allows a subscriber to create a durable subscription. This way, even if the subscriber is not activated (running), it can still receive messages from the publisher.

If you want the sent message to not be processed in any way, or to be processed by only one sender, or to be processed by multiple consumers, then you can use the Pub/Sub model.

JMS message basic components

ConnectionFactory

There are two factories for creating Connection objects: QueueConnectionFactory and TopicConnectionFactory for two different jms message models. The ConnectionFactory object can be found through JNDI.

Destination

Destination means the destination of message producers' messages or the source of messages for message consumers. For a message producer, its destination is a queue or a topic; for a message consumer, its destination is also a queue or a topic (i.e. the source of the message).

Therefore, Destination is actually two types of objects: Queue and Topic. Destination can be found through JNDI.

Connection

Connection represents the link established between the client and the JMS system (a wrapper for a TCP/IP socket). A Connection can generate one or more Sessions. Like ConnectionFactory, Connection also has two types: QueueConnection and TopicConnection.

Session

Session is an interface for operating messages. Producers, consumers, messages, etc. can be created through sessions. Session provides transaction functionality. When you need to use a session to send/receive multiple messages, you can put these send/receive actions into a transaction. Similarly, it is also divided into QueueSession and TopicSession.

Producer of message

A message producer is created by a Session and is used to send messages to a Destination. Similarly, there are two types of message producers: QueueSender and TopicPublisher. You can call the message producer's method (send or publish method) to send messages.

Message Consumer

Message consumers are created by Session to receive messages sent to Destination. Two types: QueueReceiver and TopicSubscriber. It can be created through session's createReceiver(Queue) or createSubscriber(Topic) respectively. Of course, you can also use the createDurableSubscriber method of the session to create a persistent subscriber.

MessageListener

Message listener. If a message listener is registered, once a message arrives, the listener's onMessage method will be automatically called. MDB (Message-Driven Bean) in EJB is a kind of MessageListener.

Transport

ActiveMQ currently supports the following Transports: VM Transport, TCP Transport, NIO Transport, SSL Transport, Peer Transport, UDP Transport, Multicast Transport, HTTP and HTTPS Transport, WebSockets Transport, Failover Transport, Fanout Transport, Discovery Transport, ZeroConf Transport, etc.

• VM Transport: Allows the client and Broker to communicate directly inside the VM. The connection used is not a Socket connection, but a direct method call, thus avoiding the overhead of network transmission. The application scenario is also limited to the Broker and the client in the same JVM environment.
• TCP Transport: The client connects to the remote Broker through a TCP Socket. Configuration syntax:
• tcp://hostname:port?transportOptions
• HTTP and HTTPS Transport: Allows clients to connect using REST or Ajax. This means that it is possible to send messages to ActiveMQ directly using Javascript.
• WebSockets Transport: Allows clients to connect to the Broker via HTML5 standard WebSockets.
• Failover Transport: Qinglong System MQ uses this connection method. This method has an automatic reconnection mechanism and works on top of other Transport layers to establish reliable transmission. It is allowed to configure any number of URIs, and the mechanism will automatically select one of them to try to connect. Configuration syntax:
• failover:(tcp://localhost:61616,tcp://localhost:61617,.....)?transportOptions
• Fanout Transport: Mainly suitable for sending production messages to multiple agents. If multiple brokers have loops, consumers may receive duplicate messages. Therefore, when using this protocol, it is best to send messages to multiple disconnected brokers.

Persistence

AMQ Message Store

The default persistent storage method of ActiveMQ 5.0.

Kaha Persistence

This is a solution specifically for message persistence. It is optimized for typical messaging usage patterns.

JDBC Persistence

Currently supported databases are: Apache Derby, Axion, DB2, HSQL, Informix, MaxDB, MySQL, Oracle, Postgresql, SQLServer, Sybase.

Disable Persistence

No persistent storage is used.

Cluster Solution (Master / Slave)

Pure Master Slave

• No single point of failure;
• No need to rely on shared file systems or shared databases, use KahaDB for persistent storage;
• A Master can only have one Slave;
• During the operation of the Master, the message status will be automatically synchronized to the Slave;
• Once the Master crashes, the Slave automatically takes over its work, and the messages that have been sent but not yet consumed continue to be valid;
• After the Slave takes over, the Slave must be stopped to restart the previous Master;

Shared File System Master Slave

JDBC Master Slave

• In terms of configuration, there is no distinction between Master and Slave. Multiple Brokers that share a data source constitute JDBC Master Slave.
• The broker that first grabs the resource (database lock) becomes the master, and other brokers try to grab the resource regularly;
• Once the Master crashes, other Brokers will seize resources, and only one will succeed and become the Master immediately. Even if the previous Master restarts successfully, it can only wait as a Slave.

Installation Instructions

Docker is used for installation here, query the Docker image:

docker search activemq

Download the Docker image:

docker pull webcenter/activemq

Create & run the ActiveMQ container:

docker run -d --name myactivemq -p 61617:61616 -p 8162:8161 webcenter/activemq

61616 is the port used by the activemq container (mapped to 61617), 8161 is the web page management port (mapped to 8162 externally)

Check the created container. If it exists, the installation is successful:

docker ps

View the WEB management page:

Enter http://ip:8162 in the browser, click Manage ActiveMQ broker and use the default account/password: admin/admin to view.

Configure access password

Enter the Docker container:

docker exec -it myactivemq /bin/bash

Set the user name and password on the console interface:

# Located in the root directory conf directory vi jetty-realm.properties

# Change password# username: password [,rolename ...]
admin: admin, admin

Configure the connection password

Edit the activemq.xml file and place it below shutdownHooks.

<!-- Add the account and password to access ActiveMQ-->
<plugins>
  <simpleAuthenticationPlugin>
    <users>
      <authenticationUser username="${activemq.username}" password="${activemq.password}" groups="users,admins"/>
    </users>
  </simpleAuthenticationPlugin>
</plugins>

Modify the credentials.properties file in conf to set the password:

activemq.username=admin
activemq.password=123456
guest.password=123456

Precautions

If it is a cloud server, remember to open the relevant ports (61617/8160)

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.