1. Service to hang
ActiveMQ storage mechanisms:
Under normal circumstances, the non-persistent messages are in memory, persistent memory is stored in the message file, disposed in their maximum limits node configuration file.
If, in a non-persistent messages accumulate to a certain extent, the memory ran out of time, ActiveMQ will be in memory of the non-persistent messages are written to a temporary file to free up memory.
Although are saved to the file, but the difference between it and the message is persistent, persistent message after the restart to recover from the file, the non-persistent temporary files will be deleted directly.
Persistent storage
When the message is large enough, persistent message store file exceeds the maximum limit (such as setting the maximum file 2G).
At this time, the producers send messages blocked, but consumers may be connected properly and consume messages, and so consumed part of the message, and then delete the file to free up space, but also producers continue to send the message, the service automatically return to normal.
Non-persistent storage
When using non-persistent message is provided when the message is large enough, the non-persistent message store file exceeds the maximum limit (assuming the maximum set 2G).
At this time the producers obstruction, and consumers can connect, but can not consume or otherwise slow consumer spending, consumer suddenly stopped. The entire system can be connected, but can not provide the service, it is so hung up.
solution:
In this case, it can be seen in order to ensure the security and stability message service, preferably using persistent message, if not, in some cases temporary file limit should be increased.
2. The message is lost
This unusually java from the start of java.net.SocketException.
Simply put, it is when the sender sends a bunch of network data, and then call Close to close the connection. These data are sent in the cache of the recipient, the recipient to read the data if you call the method still read from the cache, even though the other side has closed the connection. But when the receiver attempts to send data at this time since the connection has been closed, so the exception will occur, this is well understood. But note that, when the SocketException occurs, the data in the buffer zone had also set aside, at this time again the recipient calls the read method to read data in the cache, it will report Software caused connection abort: recv failed error.
Capture by that, every 10 seconds the ActiveMQ will send a heartbeat packet, the server is to send the heartbeat packet to the client, the client is determined to death did not die. If you read the first article above, you know that the accumulation of non-persistent messages to a certain extent be written to a file, the writing process will block all actions and will last 20-30 seconds, and with the increased memory increases. When the client finished his message calling connection.close (), the server will look for answers to close the connection, if more than 15 seconds did not answer directly call close socket layer close tcp connected. At this time the message sent by the client is actually still waiting to be processed in the server's cache, but since the server heartbeat packets, leading to an abnormal java.net.SocketException, the data cache set aside, the message did not deal with the lost.
solution:
With persistent messages, or non-persistent messages do not accumulate in time, or start a transaction, the transaction after the start, commit () method will be responsible to wait for the server to return, it will not close the connection that caused the message is lost.
3. Persistent messages very slowly.
By default, non-persistent messages are sent asynchronously, persistent messages are sent synchronously, encountered little slower hard drive, fast to send messages is intolerable. But in the case of open transactions, messages are sent asynchronously, efficiency will be two orders of magnitude improvement. So when sending persistent messages, be sure to activate transaction mode. In fact, when the transaction is sent also recommended to open a non-persistent messages, because there will not affect performance.
4. non-uniform consumption of the message.
Sometimes after sending some messages, open two consumers to process the message. You will find a consumer handles all the messages and one that consumers do not receive the message. The reason is that ActiveMQ the prefetch mechanism. When consumers go to get the message, not one by one to get, but a number of one-time acquisition, the default is 1000. These pre-acquisition news, not confirmed prior to consumption, the management console can still see these messages, but not reassigned to other consumers, this time the status of these messages should be considered "non-consumption has been assigned" If the message is finally consumption, it will be deleted on the server side, if consumers collapse, these messages will be reassigned to new customers. But if the consumer does not consume confirmation, not collapse, and that these messages will never lie consumer buffer zone can not handle. More often the case, the consumption of these messages very time consuming, you opened 10 consumer to deal with, and found that only one machine Hangchihangchi process, in addition to nine losers quit.
solution:
The prefetch is set to 1, each processing a message, go get processed, so also not much slower.
The dead letter queue.
If you want to post a message in the process fails, the server is not deleted, can also be treated by other consumers or retry can be closed AUTO_ACKNOWLEDGE, the ack referred to the program with their own. If you use that AUTO_ACKNOWLEDGE, when the message is to be confirmed, there is a method to confirm the news did not stop? Have!
Consumer news there are two ways, one is calling consumer.receive () method, which will block until and returns a message. In this case, after the message is returned to the caller is automatically method was confirmed. Another method is to use a callback function listener, when the message arrives, the onMessage method will be called listener interface. In this case, after the onMessage method completes, the message will be confirmed in this case as long as the method throws an exception, the message will not be acknowledged. So the question is, if a message can not be processed and will be returned to the server reassigned, if there is only one consumer, the message will be re-acquire and re-throw an exception. Even if there are multiple consumers, often on a news server can not handle, still can not be processed on another server. Is it such a return - get - given the cycle of death yet?
After retry six times, ActiveMQ believe this message is "toxic", will be thrown into the dead-letter message queue. If your message is gone, go look for ActiveMQ.DLQ years, maybe there lay
6. ActiveMQ message in the retransmission time interval and the number of retransmissions it?
ActiveMQ: Apache is produced, most popular, strong ability to open source message bus. It is a fully supported JMS1.1 and J2EE 1.4 specification JMS Provider implementation. The JMS (Java Message Service): Java platform is on a message-oriented middleware (MOM) of the API, is used between the two applications, or distributed system sends a message, for asynchronous communication.
Under First of all, we have to probably understand the circumstances under which, ActiveMQ server will resend the message to consumers, here for simplicity, it is assumed messaging mode is the queue (ie the message sender and the message recipient).
① If the message recipient does not respond to MOM processed in the processing of a message, the message will be retransmitted MOM.
② team if we set a queue read-ahead parameters (consumer.prefetchSize), if the recipient of the message All messages while processing the first message (MOM sends a message to not receiving an acknowledgment) to the down, the number of read-ahead will be retransmitted!
③ If the Session is a transaction, as long as there is a message without the message recipient confirmation, or during or MOM client sends a message either suddenly goes down, all the messages in the transaction MOM scope will retransmit.
④ Here, we may be in doubt, ActiveMQ messaging server client in the end consumers know how the message is being processed more urgent the message is not a response or has been processed with no response or no chance of response is down it? In fact, all of the client machine memory are running a client ActiveMQ environment, which is responsible for caching message sent, is responsible for maintain and ActiveMQ server messaging communications, responsible for failover (fail-over), etc. All judgments are made and processed this client environments to complete.
We can come to ActiveMQ retransmission strategy (Redelivery Policy) to customize the configuration in which the configuration parameters are mainly the following:
Available properties
Property Default Description
l collisionAvoidanceFactor default value is 0.15, set the percentage of positive and negative range of conflict prevention, to take effect only when useCollisionAvoidance parameters enabled.
After 6 l maximumRedeliveries default value, the maximum number of retransmissions reaches the maximum number of times reconnection thrown. -1 for no limit frequency is not 0 indicates retransmission.
l maximumRedeliveryDelay default value of -1, the maximum transmission delay, only valid (V5.5) is true in useExponentialBackOff is assumed that the first re-connection interval of 10ms, a factor of 2, the second reconnection interval is 20ms, the third reconnection time interval of 40ms, when the reconnection time interval large maximum reconnection time interval, after each reconnection time intervals are maximum reconnection time interval.
l initialRedeliveryDelay Default 1000L, an initial retransmission time delay
l redeliveryDelay Default 1000L, retransmission delay time, initialRedeliveryDelay = 0 commencement (V5.4) when
l useCollisionAvoidance default value false, enable the function to prevent conflict, because the message is to use multiple threads to receive concurrent treatment should be related to the safety of retransmissions, avoid all concurrent threads have carried the message receiving treatment at the same point in time. All threads what will happen when dealing with the same point in time it? There should be no problem, just to balance the broker processing performance, sometimes not very busy, sometimes idle.
l useExponentialBackOff default value false, enable multiple index incrementally increase the delay time.
l backOffMultiplier default value of 5, the time interval is incremented in multiples of reconnection, only values greater than 1 and not take effect until enabled useExponentialBackOff parameters.