ActiveMQ provides a large number of "policy" (policy)

ActiveMQ provides a large number of "strategy" (Policy) , they can broker an end to management each channel "custom" messages. This article will briefly describe the main ones Policy.

A DispatchPolcicy:. Forwarding (Topic)

    This policy indicates that message to a plurality of forward end Consumer broker, sequential messages are transmitted in this order generally refer to the order of the Consumer, only valid for Topic, which has three common types:

. 1) RoundRobinDispatchPolicy: "poll" message is sequentially transmitted to each of the "subscribers." "Subscribers" list of default in accordance with the chronological order of the subscription, when forwarding the message, for the first subscriber matching the message will be moved to the end of "subscribers' list," under a "message which also means It will later be forwarded to it.

2) StrictOrderDispatchPolicy: strict and orderly, followed by a message sent to each subscriber, according to "subscribers" subscription chronological. It RoundRobin biggest difference is that there is no sequence of operations of the mobile "subscribers."

3) PriorityDispatchPolicy: "subscribers" are sorted based on "property" weight right. It requires developers first need to specify the priority for each subscriber, the default weight of each consumer are the same weight.

4) SimpleDispatchPolicy: default order of the current list of "subscribers" in accordance with. Wherein PriorityDispatchPolicy is the subclass.

    "Poll" is more commonly used strategy.

Java code 

1. <policyEntry topic=">">                
2.   <dispatchPolicy>   
3.    <roundRobinDispatchPolicy/> 
4.   </dispatchPolicy> 
5. </policyEntry> 

Two .SubscriptionRecoveryPolicy: Recovery Strategy (Topic)

    During the "failure" of non-durable subscribers or a new Topic, the volume of messages can be traced back the broker can keep. Topic premise that must be "retroactive", we can specify this property in distination address, for example: "? Order.topic consumer.retroactive = true". By default, the subscriber can only get the "Subscribe" message after the start, if Retroactive = true, so subscribers can get a list of the message before it is created. This Policy is used to control the "retroactive" message amount.

1) FixedSizedSubscriptionRecoveryPolicy: save a certain size of the message, broker will do this Topic to open up quotas RAM to save the latest news.

Java code 

1. <!-- 1K --> 
2. <fixedSizedSubscriptionRecoveryPolicy maximumSize="1024"/> 

2) FixedCountSubscriptionRecoveryPolicy: save the message in a certain number of strips.

Java code 

1. <! - 100 -> 
2. <fixedCountSubscriptionRecoveryPolicy maximumSize="100"/> 

3) LastImageSubscriptionRecoveryPolicy: retaining only the latest piece of data

4) QueryBasedSubscriptionRecoveryPolicy: Message in line with the top selector will be saved, concrete can "restore" the number of messages is determined by the underlying storage mechanism; for example, for non-persistent messages, as long as the memory still exists, can be restored.

5) TimedSubscriptionRecoveryPolicy: retain the most recent news.

Java code 

1. <! - traceable message last minute -> 
2. <timedSubscriptionRecoveryPolicy recoverDuration="60000" /> 

6) NoSubscriptionRecoveryPolicy: Close "recovery mechanism." Defaults.

Java code 

1. <policyEntry topic=">">                
2.   <subscriptionRecoveryPolicy>   
3.    <fixedCountSubscriptionRecoveryPolicy maximumSize="100"/> 
4.   </subscriptionRecoveryPolicy> 
5. </policyEntry 

Three DeadLetterStrategy:. "Dead letter" Strategy

    How Broker will manage the "dead letter." When the message expiration, or "retransmission" still can not be normal after a few messages, then the message will be removed to DeadLetter queue. After that, we can by listening to the dead letter queue, to get the relevant notification or message to make additional operations.

1) IndividualDeadLetterStrategy: the dead-letter DeadLetter into a respective channel, for Queue, the default channel is dead letter prefixes, Topic as "ActiveMQ.DLQ.Topic."; - queues Order "ActiveMQ.DLQ.Queue." , it corresponds to the dead letter channels "ActiveMQ.DLQ.Queue.Order". We use "queuePrefix" "topicPrefix" to specify the above prefix.

    By default, both the Topic or Queue, broker will use Queue to save DeadLeader, that is, the dead-letter channels usually Queue; however, developers can also be specified as Topic.

Java code 

1. <policyEntry queue="order"> 
2.   <deadLetterStrategy> 
3.     <individualDeadLetterStrategy 
4.       queuePrefix="DLQ." useQueueForQueueMessages="false" /> 
5.   </deadLetterStrategy> 
6. </policyEntry> 

    The above Order DeadLetter queue occurring in DLQ.Order stored, although this time is DLQ.Order Topic. individualDeadLetterStrategy there is a property "useQueueForTopicMessages", this value indicates whether the Topic of DeadLetter stored in the Queue, the default is true.

2) SharedDeadLetterStrategy: all DeadLetter stored in a shared queue, this is the end ActiveMQ broker default policy. Shared Queue default is "ActiveMQ.DLQ", can be set by "deadLetterQueue" attribute.

Java code 

1. <deadLetterStrategy> 
2.     <sharedDeadLetterStrategy deadLetterQueue="DLQ-QUEUE"/> 
3. </deadLetterStrategy> 

3) DiscardingDeadLetterStrategy: Broker directly abandon DeadLeatter. If the developer does not need to be concerned about DeadLetter, you can use this strategy. AcitveMQ provides a convenient plug-in: DiscardingDLQBrokerPlugin, to abandon DeadLetter.

Java code 

1. <broker> 
2.     <plugins> 
3.       <discardingDLQBrokerPlugin dropAll="true" dropTemporaryTopics="true" dropTemporaryQueues="true" /> 
4.     </plugins> 
5. </broker> 

For the three strategies, there are two very important optional parameter, "processExpired" indicates whether the message will expire into the dead-letter queue, the default is true; "processNonPersistent" indicates whether "non-persistent" message into the dead letter queue, the default is false.

Four PendingMessageLimitStrategy:. Message throttling policy (for Slow Consumer)

    This policy is only valid for Topic, valid only for nondurable subscribers, when a large number of news channels backlog, broker can keep the volume of messages. In order to prevent Topic has a slow consumers, resulting in the backlog news channel. (For Topic, a message only if all subscribers are consumer will be deleted)

1) ConstantPendingMessageLimitStrategy: reserving a fixed number of messages, if the message exceeds limit, the use of "MessageEvictionStrategy" removal message (see below).

Java code 

1. <policyEntry topic="PRICES.>"> 
2.     <!-- lets force old messages to be discarded for slow consumers --> 
3.     <pendingMessageLimitStrategy> 
4.         <constantPendingMessageLimitStrategy limit="50"/> 
5.     </pendingMessageLimitStrategy> 
6. </policyEntry> 

2) PrefetchRatePendingMessageLimitStrategy: Reserved prefetchSize multiple messages.

Java code 

1. <! - If prefetchSize 100, the reservation messages 100 2.5 * -> 
2. <prefetchRatePendingMessageLimitStrategy multiplier="2.5"/> 

Five MessageEvictionStrategy:. Message removed strategy (for Slow Consumer)

    With PendingMessageLimitStrategy, only Topic effective, valid only for nondurable subscribers. When the number of PendingMessage exceeds the limit, broker how to eliminate redundant messages. When the Topic received information message, the message will be "Copy" to each subscriber, when you save this message (see [8] to save the policy), will be the number of detected pendingMessages exceeds limit (by the [four] to detect ), if the limit is exceeded, the excess will be used to remove MessageEvicationStrategy message pendingMessages, after which a new message stored in pendingMessages in.

1) OldestMessageEvictionStrategy: remove old messages, the default policy.

2) OldestMessageWithLowestPriorityEvictionStrategy: Heavy old data in the lower right of the message will be removed. (message.getPriority ())

3) UniquePropertyMessageEvictionStrategy: remove the old message with the specified property. Developers can specify the name of the property, the property value from the same list of messages to remove older (according to the message creation time).

Java code 

1. <policyEntry topic="SKU.PRICE.>"> 
2.     <!-- lets force old messages to be discarded for slow consumers --> 
3.     <pendingMessageLimitStrategy> 
4.         <constantPendingMessageLimitStrategy limit="10000"/> 
5.     </pendingMessageLimitStrategy> 
6.     <messageEvictionStrategy> 
7.         <uniquePropertyMessageEvictionStrategy propertyName="SKU" /> 
8.     </messageEvictionStrategy> 
9. </policyEntry> 

    The above-described configuration, for SKU.PRICE passage, retaining only the most recent message 10000, when the capacity reaches a threshold, the value of the same SKU List Message removing older message (message only kept up to date). For example, in each message, are encapsulated a SKU (product ID) of the latest price, then this strategy, keep the most recent value of a message of the same SKU.

Six SlowConsumerStrategy:. Slow Consumer Strategy

    Broker how to deal with slow consumer. Broker will start a background thread to detect all of the slow consumer and regularly close close them.

1) AbortSlowConsumerStrategy: Interrupt consumers slow, slow consumption will be closed.

Java code 

1. <slowConsumerStrategy>   
2.     <AbortSlowConsumerStrategy abortConnection = "false" /> <-! Without closing the underlying link ->   
3. </slowConsumerStrategy> 

2) AbortSlowConsumerStrategy: If consumers slow last ACK from the time interval exceeds the threshold current is interrupted slow consumer.

Java code 

1. <slowConsumerStrategy>   
2.     <abortSlowConsumerStrategy  maxTimeSinceLastAck="30000"/><!-- 30秒滞后 -->   
3. </slowConsumerStrategy> 

Seven PendingQueueMessageStoragePolicy:. To be consumer information policy

    When a large number of channels Slow Consumer, Broker how to optimize forwarding the message, and in this case, "non-persistent" how to handle the message memory limit is reached.

    When the Broker receives messages, the latest news is usually written to memory in order to improve the efficiency of message forwarding, message ACK improve efficiency and reduce operations on the underlying Store; if the Consumer is very fast, the message will be immediately forwarded to the Consumer, no additional action; but when encountered Slow Consumer, the situation does not seem so good.

    Persistent message, typically: Store write -> thread polling data from the Store to the pageIn PendingStorage - forwarding> to Consumer -> removed from the PendingStorage -> After removal from the Store Message ACK.

    For non-persistent data, typically: write memory -> If memory is sufficient, the PendingStorage directly to in-memory message forwarding -> If insufficient memory is the memory of a message to a temporary swap file -> from pageIn temporary file into memory, forwarded to the Consumer.

    AcitveMQ provides several mechanisms of Cursor, which is used to save Pending Messages.

1) vmQueueCursor: the message to be forwarded is stored in additional memory (JVM linkeList) of the storage structure. "Non-persistent messages," the default setting, if Broker does not support Persistent, it is the default setting for any type of message. There OOM risk.

2) fileQueueCursor: Save the message to a temporary file. File storage tempDataStore property has a broker's decision. It is "persistent messages," the default setting.

. 3) storeCursor: "integrated" is set for non-persistent messages, will be used vmQueueCursor storage for persistent messages are fileQueueCursor. It is strongly recommended strategy, but also the efficiency of the best strategy.

Java code 

1. <- save when persistent is true, to the "overflow" of non-persistent messages for temporary files -!> 
2. <broker persistent="true"> 
3.     <persistenceAdapter> 
4.         <!-- 
5.         <kahaDB directory="${activemq.data}/kahadb"/> 
6.         --> 
7.         <levelDB directory="${activemq.data}/leveldb"/> 
8.     </persistenceAdapter> 
9.     <-! Temporary files are stored, by default does not store any temporary files -> 
10.     <TempDataStore> 
11.         <!-- 
12.         <pListStoreImpl directory="${activemq.data}/tmp"/> 
13.         --> 
14.         <levelDB directory="${activemq.data}/leveldb/tmp"/> 
15.     </ TempDataStore> 
16.     <! - memory limit is 512M, and if it exceeds the threshold, the rollover -> 
17.     <policyEntry queue=">" producerFlowControl="true" memoryLimit="512mb">                
18.         <pendingQueuePolicy>   
19.             <storeCursor> 
20.                 <nonPersistent> 
21.                     <fileQueueCursor/> 
22.                 </nonPersistent> 
23.             </storeCursor> 
24.         </pendingQueuePolicy>   
25.     </policyEntry> 
26.     <systemUsage>     
27.         <systemUsage sendFailIfNoSpace="true">     
28.            <memoryUsage>   
29.             <! - total memory size of all message channels cache, memoryLimit as submodules ->        
30.              <memoryUsage limit="6gb"/>  
31.            </memoryUsage>     
32.         </systemUsage>     
33.     </systemUsage>  
34. </broker> 

八. PendingSubscriberMessageStoragePolicy:(Topic)

    For "nondurable" subscribers. The concept and (vii) as supports three strategies: storeCursor, vmCursor and fileCursor.

九. PendingDurableSubscriberMessageStoragePolicy: (Topic)

    For "durable" subscribers, supports three strategies: storeDurableSubscriberCursor, vmDurableCursor and fileDurableSubscriberCursor.

Java code 

1. <policyEntry topic=">" producerFlowControl="false" memoryLimit="32mb">   
2.     <pendingSubscriberPolicy>   
3.         <! - For non-durable subscribers, non-persistent messages: vmCursor, fileCursor ->   
4.          <fileCursor/>   
5.     </pendingSubscriberPolicy>   
6.     <pendingDurableSubscriberPolicy>   
7.         <! - For durable subscribers, non-persistent messages ->   
8.         <!-- storeDurableSubscriberCursor -->   
9.         <!-- vmDurableCursor -->   
10.         <!-- fileDurableSubscriberCursor -->   
11.         <storeDurableSubscriberCursor/>   
12.     </pendingDurableSubscriberPolicy>   
13. </policyEntry> 

Ten ForcePersistencyModeBrokerPlugin:. Message Transfer Mode cast widget

    The message broker receives the cast to "PERSISTENT" or "NOT_PERSISTENT".

Java code 

1. <broker> 
2.     <plugins> 
3.         <! - all messages of the transmission mode, to modify the "PERSISTENT" -> 
4.       <forcePersistencyModeBrokerPlugin persistenceFlag="true"/> 
5.     </plugins> 
6. </broker>