Nav

VM Connector

The VM Connector is for intra-app and inter-app communication through asynchronous queues that can be transient or persistent.

  • Transient queues are faster than persistent queues, but they not reliable in the case of a system crash.

  • Persistent queues are slower but reliable.

When running on a single instance, persistent queues work by serializing and storing the contents on the disk.

When running in cluster mode, persistent queues are backed by the memory grid. This means that when a flow uses the VM connector to publish content to a queue, Mule runtime will determine whether to process that message in the same origin node or to send it to the cluster for another node to pick it up. So using the VM module makes it easy to distribute the load across the cluster.

Either way, transactions are always supported.

When to use the VM Connector

Use the VM connector when:

  • You want to pass messages from one flow to another through a queuing mechanism, instead of using <flow-ref /> directly.

  • When you want to distribute work across a cluster.

  • When you want to communicate with different apps that are running in the same Mule domain.

  • When you need simple queueing that does not justify a full JMS broker.

Defining Queues

A VM config defines the queues on which the connector operates. You can define any number of configurations, each with its own set of queues, for example:


         
      
1
2
3
4
5
6
<vm:config name="vm">
    <vm:queues>
        <vm:queue queueName="transientQueue" queueType="TRANSIENT" />
        <vm:queue queueName="persistentQueue" queueType="PERSISTENT" />
    </vm:queues>
</vm:config>

It is important to note that each queue defined within a given config can only be used by operations referencing that specific config. A queue name (queueName) cannot be repeated across configs, and no two queues with the same name can exist in the same app or domain.

Limitations of Persistent Queues

When using persistent queues, the messages are either written to disk or distributed across the cluster, which requires sending the message through the network. In either case, the message needs to be serialized. This means that the contents you send must be serializable. Even though you can enable Kryo serialization to get a wider range of serializable values, Kryo does have some limitations. So, when using persistent queues try to:

  • Keep your values simple. Overly complex structures might result in serialization errors or performance issues if they are not easy to serialize.

  • When using complex Java objects, make sure they implement the Serializable interface and that they conform to the Java Bean contract.

  • Streams, JSON objects, maps, and so on are usually okay so long as the associated values comply with the recommendations above.