ActiveMQ

From Null-pointer

Java VM

The Virtual machine has been assigned 1024MB.

ACTIVEMQ_OPTS="-Xms1024M -Xmx1024M"

Tricks to optimize vertical scaling ... Allocate more memory to broker ... ^[1]

System settings

<systemUsage>
    <systemUsage sendFailIfNoSpaceAfterTimeout="2000">
        <memoryUsage>
            <memoryUsage limit="512 mb"/>
        </memoryUsage>
        <storeUsage>
            <storeUsage limit="1 gb" name="foo"/>
        </storeUsage>
        <tempUsage>
            <tempUsage limit="100 mb"/>
        </tempUsage>
    </systemUsage>
</systemUsage>

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. ^[2]

<memoryUsage limit="512 mb"/>

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

<storeUsage limit="1 gb" name="foo"/>

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

Policy settings

<policyEntry queue=">" producerFlowControl="true" optimizedDispatch="true" memoryLimit="124mb" queuePrefetch="10">

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.^[3]

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.^[3]

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. ^[4]

Transport Connector

<transportConnector name="openwire" uri="nio://0.0.0.0:61761" discoveryUri="multicast://239.255.2.3:61788?group=gib"/>

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.^[1]

Producer settings

jms.broker.url=tcp://localhost:61860?jms.useAsyncSend=true&jms.optimizedAcknowledge=true

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. ^[5]

jms.optimizeAcknowledge=true

Network Connector

<networkConnector name="bridge" 
    uri="static:(ssl://93.93.83.137:61443?keepAlive=true)" 
    duplex="true" networkTTL="6" 
    decreaseNetworkConsumerPriority="true" 
    suppressDuplicateQueueSubscriptions="true"/>

networkTTL

The network TTL has to be large enough for messages to reach the most distant brokers in the network.^[6]

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.^[6]

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.^[6]

Setting up the Key and Trust Stores

Setting up the Key and Trust Stores^[7] 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:

[root@localhost ~]# keytool -genkey -alias broker -keyalg RSA -keystore broker.ks

2. Export the broker's certificate so it can be shared with clients:

[root@localhost ~]# keytool -export -alias broker -keystore broker.ks -file broker_cert

3. Create a certificate/keystore for the client:

[root@localhost ~]# keytool -genkey -alias client -keyalg RSA -keystore client.ks

4. Create a truststore for the client, and import the broker's certificate. This establishes that the client "trusts" the broker:

[root@localhost ~]# keytool -import -alias broker -keystore client.ts -file broker_cert

Broker settings

N.B. The tags are in alphabetical order.

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

<broker>
        <sslContext>
    		<sslContext 
      		keyStore="broker.ks" keyStorePassword="password01"
      		trustStore="client.ts" trustStorePassword="password01"/>
    	</sslContext>
</broker>

References

↑ ^1.0 ^1.1 "Vertical Scaling"
↑ "Producer Flow Control" Retrieved 4 Nov 2011.
↑ ^3.0 ^3.1 "Prefetch limit"
↑ "Threading Optimizations"
↑ "Async send"
↑ ^6.0 ^6.1 ^6.2 "Optimizing Routes" Retrieved 21 Apr 2011.
↑ "Setting up the Key and Trust Stores" Retrieved 16 Mar 2011.

Retrieved from "http://www.null-pointer.co.uk/wiki/index.php/ActiveMQ"

Category: Infrastructure