Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.2)
  3. Advanced Usage of Mule ESB 3

  4. Configuring Queues

Configuring Queues

This page describes how Mule uses queues and how you configure them. Most of the information on this page applies to Mule 3.1.x and Mule 3.2. However, a number of changes have been made in Mule 3.2 that change the way queues are configured. These changes are described in Changes in Mule 3.2 – the material in that section applies only to Mule 3.2.

A queue is a structure that Mule uses to store objects during asynchronous message processing. When a message comes into a receiver at the start of an asynchronous message process, the receiver stores the message in a queue until it can be processed by a thread in a thread pool. Once it puts the message in a queue, the receiver can then immediately return and accept a new incoming message. The receiver does not have to wait for the message to be further processed before it can accept a new incoming message, so in essence, queues enable asynchronous processing in Mule.

Note that users of the Enterprise Edition of Mule ESB can use the management console to monitor queues and gain historical insight into the numbers of messages they have contained. For details, see Using the Mule Management Console.

How Mule Uses Queues

Mule uses queues for SEDA services and VM transports.

How Mule Uses Queues for SEDA Services

By default, Mule uses the SEDA model for services. The SEDA model is asynchronous. When requests come into a SEDA service, they are stored on a queue until threads from the component thread pool can pick them up and process them. An asynchronous service uses a connector receiver and a dispatcher. The connector receiver has a thread pool with a certain number of threads available to process requests on the inbound endpoints that use that connector. The chosen receiver thread puts the message in a queue. The receiver thread is then released back into the receiver thread pool so it can carry another incoming message. Finally, the chosen component thread transfers the asynchronous message to a dispatcher thread where it is sent on its way.

For further information about the use of thread pools in services, see About Threads in Mule.

How Queues are Used in VM Transports

By default, Mule uses queues in the asynchronous processing of messages that use the VM transport. The VM transport can be used for flows or services, where all the message processing is done in the JVM in which the Mule instance is running.

When requests come into a receiver for a flow or service that uses the VM transport, they are stored on a queue until threads from a thread pool can pick them up and process them. As is the case for SEDA services, the receiver thread is then released back into the receiver thread pool so it can carry another incoming message. Each message waiting in the queue can be assigned a different thread from the pool of threads.

Non-Persistent and Persistent Queues

Queues can be either non-persistent or persistent. A non-persistent queue is maintained in memory. When Mule uses a non-persistent queue for a flow or service, and the flow or service is halted either because a stop() call has been issued against that service or Mule has begun shutting down for whatever reason, the flow or service processes all messages in the queue before executing the stop order.

By contrast, when Mule uses a persistent queue for a flow or service and a stop() command comes in, Mule immediately stops accepting new messages. It then completes processing of all messages currently being processed before it shuts down. Mule does not begin the processing of any messages still waiting in the queue, because copies of these messages are in non-volatile storage (for example, a disk file) – the messages can be processed after Mule restarts and the flow or service is once again available.

If a non-persistent queue is in use for a flow or service, and the flow or service is paused when stop() is called, all messages pending processing in the queue are lost.

You can ensure that all message are saved when Mule exits by doing the following:

  • Implement persistent SEDA queues.

  • Specify transports that support persistence for all of Mule’s internal message channels.

To further insure that no messages are lost, you can design your Mule deployment so that all transactions employ synchronous endpoints. By definition, synchronous endpoints do not use queues. Note that synchronous implementations, in general, cannot match the performance of queued solutions.

Configuring Queues

You configure a queue for a SEDA service or VM transport through a queue profile. The queue profile specifies how the queue behaves. Typically, you do not need to configure the queue profile for performance, since the default configuration is usually sufficient, that is, the queue is not the bottleneck. (Performance is usually limited by the service component or one of the endpoints). For other reasons, you still might want to specify a maximum queue size, or enable persistence on the queue (which is disabled by default).

You configure the queue profile using the <queue-profile> element. For SEDA services, you specify the <queue-profile> element on the model and/or services, where services inherit the queue configuration from the model but override it if a <queue-profile> is configured explicitly on a service.

For a VM transport, you specify the <queue-profile> element on the connector.

Here are the attributes of the <queue-profile> element:

Name Type Required Default Description

maxOutstandingMessages

integer

no

Defines the maximum number of messages that can be queued.

persistent

boolean

no

false

Specifies whether Mule messages are persisted to a store. Primarily, this is used for persisting queued messages to disk so that the internal state of the server is mirrored on disk in case the server fails and needs to be restarted.

Based on the persistent attribute value you specify, Mule chooses a persistence strategy to use for the queue. By default, Mule use two persistence strategies:

  • MemoryPersistenceStrategy, which is a volatile, in-memory persistence strategy.

  • FilePersistenceStrategy, which uses a file store to persist messages to a (non-volatile) disk, and therefore maintains messages even if Mule is restarted.

The following table lists which persistence strategy is used when you set the persistent attribute in the queue-profile:

When you set persistent to . . . This is the result:

true

FilePersistenceStrategy

false

MemoryPersistenceStrategy

Currently, you cannot configure any other persistence strategies as part of the typed Mule XML configuration. However, if you need a different persistence strategy, such as to persist to a database rather than a disk, you can override the defaults in mule-default-config.xml. You achieve this by redefining the _muleQueueManager bean in your own configuration file. Such custom persistence strategies must implement QueuePersistenceStrategy.

Here are some examples:

Configure a SEDA service queue to be persistent:

<service name="serviceQueuePersist">
    ...

    <queue-profile persistent="true"/>

</service>

Configure a connector on a flow that uses the VM transport. Limit the maximum number of messages that can be queued to 100 and make the queue persistent:

<vm:connector name="persistentVmConnector" queueTimeout="1000">
   <queue-profile maxOutstandingMessages="100" persistent="true"/>
</vm:connector>

<flow>
   <vm:inbound-endpoint ... />
   <component class="org.mule.ComponentClass"/>
   <vm:inbound-endpoint path="in" connector-ref="persistentVmConnector" />
</flow>

Changes in Mule 3.2

A number of changes have been made in Mule 3.2 that that change the way queues are configured. The changes include the use of processing strategies for flows, and object stores for queues.

Processing Strategies for Flows

Mule 3.2 introduces processing strategies that determine how Mule implements message processing for a flow. One of these strategies, the queued-asynchronous processing strategy, implements SEDA queues to decouple a flow’s receiver from the other steps in a flow. This means that implicitly you configure a queue for a flow when you specify the queued-asynchronous processing strategy for the flow. For further details, see About the Queued-Asynchronous Flow Processing Strategy.

Object Stores for SEDA Queues

Storage for SEDA queues is configured in a new way in Mule 3.2. Persistence strategies are no longer used. Instead, SEDA queues now use an object store for persisting messages. The persistent attribute in the <queue-profile> element has been replaced by a child element of <queue-profile>. The child element identifies the object store for the SEDA queue.

By default, Mule uses an in-memory object store for SEDA queues (for a cluster, Mule creates the default in-memory store in the shared memory grid). Mule provides a number of object store choices. These are as follows:

  • queue-store: References the global queue store.

  • default in-memory-queue-store: The default in-memory store.

  • default persistent-queue-store: A file-based store. For a cluster, it is the default in-memory store.

  • simple in-memory queue-store. Always an in-memory store.

  • file queue store. Always a file-based store.

For example, the following configures a SEDA service queue to use a file-based object store:

<service name="serviceFileObjectStore">
    ...

    <queue-profile>
        <file-queue-store/>
    </queue-profile>
</service>

In most cases, the default object store should meet your needs. However, you can specify which object store to use. For example, you might want to enable persistence for the queue by specifying the default persistent-queue-store, and in this way override the default in-memory queue store.

For more details, see Mule Object Stores.