1. What is ActiveMQ?
activeMQ is an open source, message-oriented (MOM) middleware that implements the JMS1.1 specification, and provides efficient, scalable, stable and secure enterprise-level message communication for applications
2. What should I do if the ActiveMQ server is down?
This starts with the storage mechanism of ActiveMQ. Under normal circumstances, non-persistent messages are stored in memory, and persistent messages are stored in files, and their maximum limits are configured in the node of the configuration file. However, when the non-persistent messages accumulate to a certain extent and the memory is in a hurry, ActiveMQ will write the non-persistent messages in the memory into a temporary file to free up memory. Although they are all saved in files, the difference between it and persistent messages is that persistent messages will be restored from the file after restart, and non-persistent temporary files will be deleted directly.
What happens if the file size reaches the maximum limit in the configuration? I did the following experiment:
Set a persistent file limit of about 2G, and mass-produce persistent messages until the file reaches the maximum limit. At this time, the producer is blocked, but the consumer can connect and consume the message normally. After a part of the message is consumed and the file is deleted to make room, The producer can continue to send messages, and the service automatically returns to normal.
Set a temporary file limit of about 2G, mass-produce non-persistent messages and write temporary files. When the maximum limit is reached, the producer is blocked, and consumers can connect normally but cannot consume messages, or consumers who are originally slow-consuming, consume Stop suddenly. The entire system can be connected, but cannot provide services, so it hangs.
The specific reason is unknown. Solution: Try not to use non-persistent messages. If you have to, increase the temporary file limit as much as possible.
3. What should I do if I lose a message?
This has to start with java.net.SocketException. Simply put, it is when the network sender sends a bunch of data and then calls close to close the connection. These sent data are in the receiver's cache, and the receiver can still read the data from the cache if the read method is called, even though the other party has closed the connection. But when the receiver tries to send data, because the connection is closed at this time, an exception will occur, which is easy to understand. However, it should be noted that when a SocketException occurs, the data in the original buffer area is also invalid. At this time, the receiver calls the read method again to read the data in the buffer, and a Software caused connection abort: recv failed error will be reported.
Through packet capture, ActiveMQ will send a heartbeat packet every 10 seconds. This heartbeat packet is sent by the server to the client to determine whether the client is dead or not. If you have read the first one above, you will know that non-persistent messages will be written to the file when they accumulate to a certain extent. This writing process will block all actions, and it will last 20 to 30 seconds, and as the memory increases And increase. When the client finishes sending the message and calls connection.close(), it expects the server's answer to closing the connection. If there is no answer for more than 15 seconds, it will directly call the socket layer close to close the tcp connection. At this time, the message sent by the client is still waiting to be processed in the server's cache, but due to the setting of the server's heartbeat packet, a java.net.SocketException occurs, which invalidates the data in the cache, and all unprocessed messages are lost.
Solution: Use persistent messages or non-persistent messages to process in a timely manner without stacking up, or start the transaction. After the transaction is started,
The commit() method will responsibly wait for the server to return, and will not close the connection and cause the message to be lost.
4. Persistent messages are very slow.
By default, non-persistent messages are sent asynchronously, and persistent messages are sent synchronously. In the case of slower hard drives, the speed of sending messages is unbearable. However, when the transaction is turned on, the messages are sent asynchronously, and the efficiency will be improved by 2 orders of magnitude. So when sending persistent messages, be sure to enable transaction mode. In fact, it is also recommended to open transactions when sending non-persistent messages, because it will not affect performance at all.
5. Uneven consumption of news.
Sometimes after sending some messages, two consumers are opened to process the messages. You will find that one consumer has processed all the messages, and the other consumer has not received the messages at all. The reason lies in the prefetch mechanism of ActiveMQ. When consumers get messages, they will not get them one by one, but will get one batch at a time. The default is 1000. These pre-acquired messages can still be seen in the management console before the consumption is confirmed, but they will not be distributed to other consumers. At this time, the status of these messages should be counted as "allocated but not consumed". If the message is finally consumed, it will be deleted on the server side. If the consumer crashes, these messages will be redistributed to new consumers. But if the consumer neither confirms the consumption nor crashes, these messages will always lie in the consumer's cache and cannot be processed. More commonly, it is very time-consuming to consume these messages. You open 10 consumers to process them, and you find that there is only one machine, 吭哧吭哧
Processing, the other 9 units do nothing.
Solution: Set prefetch to 1, process 1 message at a time, and fetch it after processing. This is not much slower.
6. Dead letter queue.
If you want to not be deleted by the server after the message processing fails, but can be processed or retried by other consumers, you can turn off AUTO_ACKNOWLEDGE and leave the ack to the program to process. Then if AUTO_ACKNOWLEDGE is used, when was the message confirmed, and is there any way to prevent the confirmation of the message? Have!
There are two ways to consume messages. One is to call the consumer.receive() method, which will block until a message is obtained and returned. In this case, the message is automatically acknowledged after it is returned to the method caller. Another method is to use the listener callback function. When a message arrives, the onMessage method of the listener interface is called. In this case, the message will be confirmed after the onMessage method is executed. At this time, as long as an exception is thrown in the method, the message will not be confirmed. Then the problem is coming. If a message cannot be processed, it will be returned to the server for redistribution. If there is only one consumer, the message will be retrieved again and the exception will be thrown again. Even if there are multiple consumers, messages that cannot be processed on one server can still not be processed on another server. Is it just returning like this
– Acquire – Is there an error loop?
After 6 retries, ActiveMQ considers the message to be "toxic" and will drop the message into the dead letter queue. If your message is gone, look for it in ActiveMQ.DLQ, and maybe just lie there.
1. What is ActiveMQ?
activeMQ is an open source, message-oriented (MOM) middleware that implements the JMS1.1 specification, and provides efficient, scalable, stable and secure enterprise-level message communication for applications
2. What should I do if the ActiveMQ server is down?
This starts with the storage mechanism of ActiveMQ. Under normal circumstances, non-persistent messages are stored in memory, and persistent messages are stored in files, and their maximum limits are configured in the node of the configuration file. However, when the non-persistent messages accumulate to a certain extent and the memory is in a hurry, ActiveMQ will write the non-persistent messages in the memory into a temporary file to free up memory. Although they are all saved in files, the difference between it and persistent messages is that persistent messages will be restored from the file after restart, and non-persistent temporary files will be deleted directly.
What happens if the file size reaches the maximum limit in the configuration? I did the following experiment:
Set a persistent file limit of about 2G, and mass-produce persistent messages until the file reaches the maximum limit. At this time, the producer is blocked, but the consumer can connect and consume the message normally. After a part of the message is consumed and the file is deleted to make room, The producer can continue to send messages, and the service automatically returns to normal.
Set a temporary file limit of about 2G, mass-produce non-persistent messages and write temporary files. When the maximum limit is reached, the producer is blocked, and consumers can connect normally but cannot consume messages, or consumers who are originally slow-consuming, consume Stop suddenly. The entire system can be connected, but cannot provide services, so it hangs.
The specific reason is unknown. Solution: Try not to use non-persistent messages. If you have to, increase the temporary file limit as much as possible.
3. What should I do if I lose a message?
This has to start with java.net.SocketException. Simply put, it is when the network sender sends a bunch of data and then calls close to close the connection. These sent data are in the receiver's cache, and the receiver can still read the data from the cache if the read method is called, even though the other party has closed the connection. But when the receiver tries to send data, because the connection is closed at this time, an exception will occur, which is easy to understand. However, it should be noted that when a SocketException occurs, the data in the original buffer area is also invalid. At this time, the receiver calls the read method again to read the data in the buffer, and a Software caused connection abort: recv failed error will be reported.
Through packet capture, ActiveMQ will send a heartbeat packet every 10 seconds. This heartbeat packet is sent by the server to the client to determine whether the client is dead or not. If you have read the first one above, you will know that non-persistent messages will be written to the file when they accumulate to a certain extent. This writing process will block all actions, and it will last 20 to 30 seconds, and as the memory increases And increase. When the client finishes sending the message and calls connection.close(), it expects the server's answer to closing the connection. If there is no answer for more than 15 seconds, it will directly call the socket layer close to close the tcp connection. At this time, the message sent by the client is still waiting to be processed in the server's cache, but due to the setting of the server's heartbeat packet, a java.net.SocketException occurs, which invalidates the data in the cache, and all unprocessed messages are lost.
Solution: Use persistent messages or non-persistent messages to process in a timely manner without stacking up, or start the transaction. After the transaction is started,
The commit() method will responsibly wait for the server to return, and will not close the connection and cause the message to be lost.
4. Persistent messages are very slow.
By default, non-persistent messages are sent asynchronously, and persistent messages are sent synchronously. In the case of slower hard drives, the speed of sending messages is unbearable. However, when the transaction is turned on, the messages are sent asynchronously, and the efficiency will be improved by 2 orders of magnitude. So when sending persistent messages, be sure to enable transaction mode. In fact, it is also recommended to open transactions when sending non-persistent messages, because it will not affect performance at all.
5. Uneven consumption of news.
Sometimes after sending some messages, two consumers are opened to process the messages. You will find that one consumer has processed all the messages, and the other consumer has not received the messages at all. The reason lies in the prefetch mechanism of ActiveMQ. When consumers get messages, they will not get them one by one, but will get one batch at a time. The default is 1000. These pre-acquired messages can still be seen in the management console before the consumption is confirmed, but they will not be distributed to other consumers. At this time, the status of these messages should be counted as "allocated but not consumed". If the message is finally consumed, it will be deleted on the server side. If the consumer crashes, these messages will be redistributed to new consumers. But if the consumer neither confirms the consumption nor crashes, these messages will always lie in the consumer's cache and cannot be processed. More commonly, it is very time-consuming to consume these messages. You open 10 consumers to process them, and you find that there is only one machine, 吭哧吭哧
Processing, the other 9 units do nothing.
Solution: Set prefetch to 1, process 1 message at a time, and fetch it after processing. This is not much slower.
6. Dead letter queue.
If you want to not be deleted by the server after the message processing fails, but can be processed or retried by other consumers, you can turn off AUTO_ACKNOWLEDGE and leave the ack to the program to process. Then if AUTO_ACKNOWLEDGE is used, when was the message confirmed, and is there any way to prevent the confirmation of the message? Have!
There are two ways to consume messages. One is to call the consumer.receive() method, which will block until a message is obtained and returned. In this case, the message is automatically acknowledged after it is returned to the method caller. Another method is to use the listener callback function. When a message arrives, the onMessage method of the listener interface is called. In this case, the message will be confirmed after the onMessage method is executed. At this time, as long as an exception is thrown in the method, the message will not be confirmed. Then the problem is coming. If a message cannot be processed, it will be returned to the server for redistribution. If there is only one consumer, the message will be retrieved again and the exception will be thrown again. Even if there are multiple consumers, messages that cannot be processed on one server can still not be processed on another server. Is it just returning like this
– Acquire – Is there an error loop?
After 6 retries, ActiveMQ considers the message to be "toxic" and will drop the message into the dead letter queue. If your message is gone, look for it in ActiveMQ.DLQ, and maybe just lie there.