Skip to content

Overview

Concepts and Principles

Development

Overview

IDEs

API Explorer

Releases

Release Notes

TORO Integrate

Coder Studio

Coder Cloud

Bug Reports

Search

Tuning ActiveMQ

A messaging system is vital for processes to communicate to other processes reliably. From storage, routing, and monitoring, there needs to be systematic management of messages. To address these matters and to implement its Message Oriented Middleware (MOM) architecture, TORO Integrate makes use of ActiveMQ, an enterprise-grade message broker. ActiveMQ enables decoupled communication among applications making it easy to build seamless integrations.

Learn more about how TORO Integrate uses ActiveMQ here!

Different integrations will have different requirements. Some systems will benefit more from an increase in speed over reliability; others, the other way around. In this page, we will look at how ActiveMQ can be configured to suit your integration needs. We will discuss noteworthy properties, their benefits, and trade-offs. For this reason, it is also important that you analyze how your organization uses TORO Integrate and ActiveMQ before heading on to making adjustments.

Overridden Properties

TORO Integrate has already tuned ActiveMQ to achieve a balance between speed, reliability, and throughput. These adjustments are visible in the instance .properties file, particularly <toro-integrate-home>\conf\toro-integrate.properties. Below are the properties set for optimization:

Maximum Message Redelivery

  • Name: activemq.maxQueueRedelivery
  • Default Value: 5

Messages in ActiveMQ are redelivered in certain situations. This property specifies how many times a message should be redelivered before it goes to the Dead Letter Queue (DLQ). If you want to ensure the redelivery of messages, consider using a different acknowledgement mode.

Message Redelivery Delay

  • Name: activemq.redeliveryDelay
  • Default Value: 5000 (milliseconds)

Redelivery delay refers to the time interval between message redeliveries. You should consider the message throughput when configuring this property because a clog up on system memory may occur when too many messages are held for too long.

Asynchronous Sending

  • Name: activemq.useAsyncSend
  • Default Value: true

When publishing a message, the broker needs to send back a receipt to the publisher stating that message has been received successfully. This process adds significant overhead to the system when done synchronously. By default, this is configured to be asynchronous which tells the publisher to not wait for broker receipts. However, there might be cases of message loss since publishers will blindly publish messages to the broker. If your integration is mission-critical or you just cannot afford to lose messages, consider setting this to false instead.

Optimized Acknowledgement

  • Name: activemq.optimizeAcknowledge
  • Default Value: true

ActiveMQ can process acknowledgement receipts in batches by setting this property to true. If the batch limit is not reached after 300 milliseconds, collected messages are also acknowledged. Depending on your use case, this configuration may affect the performance of your TORO Integrate instance.

Topic Advisories

  • Name: activemq.watchTopicAdvisories
  • Default Value: false

ActiveMQ automatically creates topics prefixed with ActiveMq.Advisory. for its advisory message feature. This is mainly to provide information regarding the behavior of its components. TORO Integrate disabled this by default for performance reasons. You need to set this to true if you want to build a network of brokers because advisory topics are required for multiple broker communication.

Further Tuning

Aside from the configurations made out-of-the-box by TORO Integrate, you can further refine your ActiveMQ instance by:

Optimizing Threads

Each destination will warrant a dedicated thread assigned by ActiveMQ. If you have a large number of destinations, expect a large amount of memory usage due to memory consumed by these threads. You can configure ActiveMQ to use a thread pool instead by adding -Dorg.apache.activemq.UseDedicatedTaskRunner=false in ActiveMQ's start up script.

As of ActiveMQ 5.6, the use of dedicated task runner is disabled by default

Using NIO Transport

ActiveMQ uses TCP transport, by default, for communication. There is another transport type called NIO Transport which uses a different API that can help speed up and scale the broker. Note that NIO is a server side option only. Using this on the client side will make the configuration fallback to TCP. See the Configuring Transports page for more information on how to use NIO instead.

Tuning the ActiveMQ Instance

Another factor that can affect the messaging system performance is the ActiveMQ instance itself. Make sure the memory allocation, disk allocation, JVM, persistence configuration, and other settings are adjusted to suit your needs. You can learn how to further tune ActiveMQ on their performance tuning page.

Tuning Other Integrate Components

To further increase the performance of TORO Integrate's messaging system, you may want to tune other components as well. Most of them impact the messaging system's performance so it's a good choice to learn how to tune them. As an example, you can tune Tracker to adjust how messages are logged or the JVM to increase the overall performance.

Load Balancing

If your application needs to process huge amounts of messages, you can opt to distribute the workload over multiple TORO Integrate instances. This process is known as load balancing. Load balancing works by connecting multiple instances to a single queue. Messages are then delivered with only one instance retrieving one message from the broker at a time.

To allow load balancing, you need to configure these application properties:

  • jms.file

    If you are using a remote ActiveMQ, change this to remote-activemq.

  • jms.url

    The URL used to connect to the broker. Ensure that your instances are connecting to the same broker.

  • activemq.username

    The username used when connecting to ActiveMQ. This is set to guest, by default.

  • activemq.password

    The password used when connecting to ActiveMQ. This is set to guest, by default.

  • jms.prefix

    The destination name prefix. Ensure that your instances have the same prefix so that they share the same destinations. You can leave this blank to use non-prefixed destination names.

  • jms.clientId

    Used by the broker to uniquely identify the application. Ensure that your instances have different client IDs to allow them to be connected to the same broker.

Here's an example configuration:

  • In our first instance of TORO Integrate, we have:

    1
    2
    3
    4
    jms.file=remote-activemq
    jms.url=failover:(tcp://0.0.0.0:61616?closeAsync=false&wireFormat.maxInactivityDuration=0)
    jms.prefix=cluster1
    jms.clientId=instance1
    
  • In our second instance of TORO Integrate, we have:

    1
    2
    3
    4
    jms.file=remote-activemq
    jms.url=failover:(tcp://0.0.0.0:61616?closeAsync=false&wireFormat.maxInactivityDuration=0)
    jms.prefix=cluster1
    jms.clientId=instance2
    

After everything has been configured, you may now (re-)start your instances. If you are using a remote ActiveMQ instance, you can verify that your instances share the same destinations by accessing the ActiveMQ Web Console. Go to Queues and you should see the destinations shared by your instances. To verify that your instances are connected, click one of the destinations then View Consumers. You should now see a connection entry for each of your instances similar to:

ActiveMQ Load Balanced Connections