VM — provides an asynchronous connection to consumers in other camelContext
elements
VM endpoints provide asynchronous SEDA behavior so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread pool to the producer.
VM endpoints differ from Seda endpoints in that VM endpoints support communication across CamelContext instances.
VM is an extension to the SEDA component.
vm:queueName[?options]
Where queueName
can be any string
to uniquely identify the endpoint within the JVM (or at least within the classloader
that loaded camel-core.jar)
You can append query options to the URI in the following format:
?option=value&option=value&...
![]() | Important |
---|---|
In versions prior to Camel 2.3, an identical VM endpoint URI must be used
for both the producer and the consumer endpoints. Otherwise, Camel will create a
second VM endpoint regardless of whether the from("direct:foo").to("vm:bar?concurrentConsumers=5"); from("vm:bar?concurrentConsumers=5").to("file://output"); Notice that we have to use the full URI, including options in both the producer and consumer. In Camel 2.4 this has been fixed so that only the queue name must match. Using the
queue name from("direct:foo").to("vm:bar"); from("vm:bar?concurrentConsumers=5").to("file://output"); |
See the SEDA component for options and other important usage details, as the same rules apply to the VM component.
In the route below we send exchanges across CamelContext instances to a VM queue named
order.email
:
from("direct:in").bean(MyOrderBean.class).to("vm:order.email");
And then we receive exchanges in some other Camel context (such as deployed in another
.war
application):
from("vm:order.email").bean(MyOrderEmailSender.class);