ACTIVEMQ Learning notes-distribution strategy

Send asynchronously

ACTIVEMQ The default send mode is asynchronous send, if we use the scene is non-transactional type or need to persist the message, allow a small number of messages to be lost, it is recommended to use asynchronous send. Synchronous sending requires an acknowledgement of increased ACK, which increases latency and system consumption.

CF = new Activemqconnectionfactory ("Tcp://locahost:61616?jms.useasyncsend=true");

((activemqconnectionfactory) connectionfactory). Setuseasyncsend (True);

((activemqconnection) connection). Setuseasyncsend (True);

Distribution Policy

Pluggable distribution policies can only be used on the topic, the queue's message distribution strategy is more fixed, polling (default) or sticky order, and we should also understand the meaning of prefetch values prefetch.
The default prefetch value is very large, and the default distribution policy always fills the prefetch buffer as much as possible.
There are a lot of use cases and sometimes the default configuration is not very good work, such as you send a small number of messages, but the broker to wait until a large number of messages to a consumer, while each message processing takes a certain amount of time, then a large number of messages will increase processing time.

Strictorderdispatch indicates that the next consumer is selected for distribution of messages until the current consumer's prefetch buffer is full.

<policyentry queue= ">" strictorderdispatch= "false"/>

distribution strategies for topics

The implementation of the Org.apache.activemq.broker.region.policy.DispatchPolicy class is a specific strategy for topic distribution. The default distribution policy is Org.apache.activemq.broker.region.policy.SimpleDispatchPolicy, and the network The distribution policy in is to send messages to high priority org.apache.activemq.broker.region.policy.PriorityNetworkDispatchPolicy.

<destinationPolicy> <policyMap> <policyEntries> <policyentry topic= "foo.>" > <dispatchPolicy> <roundrobindispatchpolicy/> </dispatchPolicy> <subscript
      ionrecoverypolicy> <lastimagesubscriptionrecoverypolicy/> </subscriptionRecoveryPolicy> </policyEntry> <policyentry topic= "orders.>" > <dispatchPolicy> <stri Ctorderdispatchpolicy/> </dispatchPolicy> <!--1 minutes worth--<subscripti onrecoverypolicy> <timedsubscriptionrecoverypolicy recoverduration= "60000"/> </subscription  recoverypolicy> </policyEntry> <policyentry topic= "prices.>" > <!--lets force old Messages to being discarded for slow consumers-<pendingMessageLimitStrategy> <constantpend Ingmessagelimitstrategylimit= "Ten"/> </pendingMessageLimitStrategy> <!--seconds Worth--<subscrip tionrecoverypolicy> <timedsubscriptionrecoverypolicy recoverduration= "10000"/> </subscripti
      onrecoverypolicy> </policyEntry> <policyentry temptopic= "true" advisoryforconsumed= "true"/> <policyentry tempqueue= "true" advisoryforconsumed= "true"/> </policyEntries> </policyMap> &lt ;/destinationpolicy>

Message Cursors

A common problem with using ACTIVEMQ is that non-persisted messages can run out of memory buffers.
ActiveMQ5.0.0, the new memory model allows us to cache messages on disk storage pages, as well as to pass messages directly from the producer to the consumer (after the message has persisted).

Cursor Type

ActiveMQ 5.0 has two cursors that can select the VM cursor File based cursor

VM Cursor
Fast, but there are drawbacks when dealing with slow consumers

File based Cursor
The File based cursor is derived from the cursor of the VM, and when the broker reaches the memory limit, it is able to store the message paging to disk, which is suitable for scenarios where the message store is very slow but consumes very fast.

Paging for Non-persistent Messages
Non-persistent messages send the message directly to the cursor.

Configuring Cursors
By default, storage cursors can be used to configure different cursor policies for different queues.

Topic subscription

The valid subscription type is vmcursor,filecursor, and the valid persistent subscription cursor type is storedurablesubscribercursor, Storedurablesubscribercursor and Filedurablesubscribercursor, the default is Storedurablesubscribercursor.

<destinationPolicy>
      <policyMap>
        <policyEntries>
          <policyentry topic= "Org.apache .> "producerflowcontrol=" false "memorylimit=" 1MB ">
            <dispatchPolicy>
              < Strictorderdispatchpolicy/>
            </dispatchPolicy>
            <deadLetterStrategy>
              < Individualdeadletterstrategy  topicprefix= "test.dlq."/>
            </deadLetterStrategy>
            < pendingsubscriberpolicy>
                <vmcursor/>
            </pendingSubscriberPolicy>
            < pendingdurablesubscriberpolicy>
                <vmDurableCursor/>
            </pendingDurableSubscriberPolicy>
          </policyEntry>
        </policyEntries>
      </policyMap>
</destinationPolicy>

The cursor types for queues are storecursor, Vmqueuecursor, and Filequeuecursor, which are storecursor by default.

<destinationPolicy>
      <policyMap>
        <policyEntries>
          <policyentry queue= "Org.apache .> ">
            <deadLetterStrategy>
              <individualdeadletterstrategy queueprefix=" TEST.DLQ. " />
            </deadLetterStrategy>
            <pendingQueuePolicy>
                <vmqueuecursor/>
            </ pendingqueuepolicy>
          </policyEntry>
        </policyEntries>
      </policyMap>
 </ Destinationpolicy>

Optimization Confirmation

ACTIVEMQ supports confirming a range of messages in a single bulk operation, this feature is turned off by default, enabling this feature to reduce the load on the broker and increase the throughput of the system in some cases.

CF = new Activemqconnectionfactory ("Tcp://locahost:61616?jms.optimizeacknowledge=true");

((activemqconnectionfactory) connectionfactory). Setoptimizeacknowledge (True);

((activemqconnection) connection). Setoptimizeacknowledge (True);

The setoptimizeacknowledgetimeout is used to set the time-out for the optimization acknowledgment, which is 300 milliseconds by default, and 0 indicates that the attribute is not enabled. Producer Flow Control

ActiveMQ4.0 producer flow control using TCP traffic control, this strategy is very effective, but sharing the same connection among multiple producers and consumers can lead to deadlocks.
Since ActiveMQ5.0, we can configure shared connection for each producer without having to suspend the entire connection, traffic control means that when the broker detects the limit of memory, or the file is full, it can slow down the generation of messages, blocking producers know that resources are available, or JMSException, which we are configuring in node Systemusage.

It is important to note that the default Systemusage configuration will block the producer when the memorylimit or systemusage reaches the limit, sometimes misleading as the producer is suspended, and the consumer is actually waiting for the resource to be available. Synchronous sending of messages will automatically enable traffic control unless you turn on the Useasyncsend feature when the Useasyncsend feature is turned on, we will not receive any notifications when the memory reaches the limit, we need to configure the Producerwindowsize For enabling traffic control after the memory limit is reached

Producerwindowsize is the maximum number of bytes the producer sends to the broker before receiving an ACK limit

Activemqconnectionfactory connctionfactory = ...
Connctionfactory.setproducerwindowsize (1024000);

Or we can configure the Alwayssyncsend feature when we notice that the memory in the broker has reached the limit.

<destinationPolicy>
  <policyMap>
    <policyEntries>
      <policyentry topic= "foo.>" Producerflowcontrol= "false"/>
    </policyEntries>
  </policyMap>
</destinationpolicy >

how Producer Flow Control works

By sending an ACK to the producer to inform the producer that the number of current Windows sizes has been processed, you can continue to send the next windowsize.

Advantages
A good producer will wait until the ACK is returned and then continue sending the message to avoid flooding the traffic.

Configure client-side Exceptions
When the broker resource is low, it is also one of the options to replace the blocking operation of Send () with a micro-throw exception. When the Sendfailifnospace property is configured to True, the broker throws an javax.jms.ResourceAllocationException exception and propagates to the client.
The child send operation is not suspended, but the exception is caught and then retried. The units configured below are in milliseconds

<systemUsage>
<systemusage sendfailifnospaceaftertimeout= "+" >
<memoryUsage>
& Lt;memoryusage limit= "MB"/>
</memoryUsage>
</systemUsage>
</systemUsage>

<systemUsage>
<systemUsage>
<memoryUsage>
<memoryusage limit= "MB"/>
   </memoryUsage>
<storeUsage>
<storeusage limit= "GB"/>
</storeu sage>
<tempUsage>
<tempusage limit= "Ten GB"/>
</tempUsage>
</s Ystemusage>
</systemUsage>

Timing

Sometimes it is necessary to keep the consumer's order of conversation, and broker can guarantee the order of messages sent by the same producer, but for multithreading and asynchronous processing, the order in which messages from different producers reach different consumers is different.
such as production p and Q, send message p1,p2,p3, and q send Q1,Q2, the consumer may receive the message is

CONSUMER1:P1 P2 Q1 P3 Q2
consumer2:p1 Q1 Q2 P2 P3

Total orrdering ensures that the sequence of messages that each consumer sees is the same, but this can be a performance drain, but it is important for the transaction type system.

CONSUMER1:P1 P2 Q1 P3 Q2
consumer2:p1 P2 Q1 P3 Q2

<destinationpolicy>   <policyMap>     < policyentries>       <policyentry topic= ">" >          <dispatchPolicy>           < Strictorderdispatchpolicy/>         </dispatchPolicy>        </policyEntry>     </policyEntries>    </policyMap> </destinationpolicy>