ActiveMQ

Java VM
The Virtual machine has been assigned 1024MB. "Tricks to optimize vertical scaling ... Allocate more memory to broker ..."

System settings

 * See Producer Flow Control

sendFailIfNoSpaceAfterTimeout
"This property causes the send operation to fail with an exception on the client-side, but only after waiting the given amount of time. If space on the broker is still not freed after the configured amount of time, only then does the send operation fail with an exception to the client-side."

"The timeout is defined in milliseconds so the example above waits for three seconds before failing the send operation with an exception to the client-side. The advantage of this property is that it will block for the configured amount of time instead of failing immediately or blocking indefinitely. This property offers not only an improvement on the broker-side, but also an improvement for the client so it can catch the exception, wait a bit and retry the send operation."


This is the maximum value for the broker. This value affects the flow control.


This is the maximum value for the broker. This value affects the flow control.

memoryLimit="124mb"
This value affects the flow control. This must be less than the memoryUsage value.

queuePrefetch="1"
The prefetch value is low as there are multiple consumers.

"If you are using a collection of consumers to distibute the workload (many consumers processing messages from the same queue), you typically want this limit to be small. If one consumer is allowed to accumulate a large number of unacknowledged messages, it could starve the other consumers of messages. Also, if the consumer fails, there would be a large number of messages unavailable for processing until the failed consumer is restored."

"Queue consumers—if you have just a single consumer attached to a queue, you can leave the prefetch limit at a fairly large value. But if you are using a group of consumers to distribute the workload, it is usually better to restrict the prefetch limit to a very small number—for example, 0 or 1."

optimizedDispatch="true"
"On the broker, you can reduce the number of required threads by setting the optimizedDispatch option to true on all queue destinations. When this option is enabled, the broker no longer uses a dedicated thread to dispatch messages to each destination."

nio for transport connectors
"NIO transport on the broker—to reduce the number of threads required, use the NIO transport (instead of the TCP transport) when defining transport connectors in the broker."

jms.useAsyncSend=true
"... Since latency is typically a huge factor in the throughput that can achieved by producer, using async sends can increase the performance of your system dramatically."

networkTTL
"The network TTL has to be large enough for messages to reach the most distant brokers in the network."

The following settings have been shown, through testing, to prevent messages getting stuck on the brokers.

decreaseNetworkConsumerPriority="true"
"When decreaseNetworkConsumerPriority is set to true, the priority is set as follows:


 * Local consumers (attached directly to the broker) have a priority of 0.


 * Network subscriptions have an initial priority of -5.


 * The priority of a network subscription is reduced by 1 for every network hop that it traverses

A broker sends messages preferentially to the subscription with the highest priority, but if the prefetch buffer is full, the broker will divert messages to the subscription with the next highest priority. If multiple subscriptions have the same priority, the broker distributes messages equally between those subscriptions."

suppressDuplicateQueueSubscriptions="true"
"The effect of enabling this option is that the broker allows only a single queue subscription to be created for a given consumer. This means that only a single route can be created between a producer and a consumer, so that the routing becomes fully deterministic. In general, it is recommended that you enable both the decreaseNetworkConsumerPriority option and the suppressDuplicateQueueSubscriptions option together."

excludedDestinations
Placed within the networkConnector config, this will exclude queues from being propagated over that network connector.

Setting up the Key and Trust Stores
Setting up the Key and Trust Stores ActiveMQ uses dummy credentials by default ActiveMQ includes key and trust stores that reference a dummy self signed cert. When you create a broker certificate and stores for your installation, either overwrite the values in the conf directory or delete the existing dummy key and trust stores so they cannot interfere)

1. Using keytool, create a certificate for the broker: 2. Export the broker's certificate so it can be shared with clients: 3. Create a certificate/keystore for the client: 4. Create a truststore for the client, and import the broker's certificate. This establishes that the client "trusts" the broker:

Broker settings
N.B. The tags are in alphabetical order.

Place the keystore and truststore in the conf folder of the activeMQ:

The limitations of JMS durable topics
A JMS durable subscriber MessageConsumer is created with a unique JMS clientID and durable subscriber name. To be JMS compliant only one JMS connection can be active at any point in time for one JMS clientID, and only one consumer can be active for a clientID and subscriber name. i.e., only one thread can be actively consuming from a given logical topic subscriber. This means we cannot implement


 * load balancing of messages.
 * fast failover of the subscriber if that one process running that one consumer thread dies.