The vm: component provides asynchronous SEDA behavior so that messages are exchanged on a BlockingQueue and consumers are invoked in a separate thread pool to the producer.
This component differs from the Seda component in
that VM supports communication across CamelContext instances, so you can use this
mechanism to communicate across web applications, provided that the
camel-core.jar
is on the system/boot
classpath.
This component is an extension to the Seda component.
vm:someName[?options]
Where someName can be any string to uniquely identify the endpoint within the JVM (or at least within the classloader which loaded the camel-core.jar)
You can append query options to the URI in the following format,
?option=value&option=value&...
Camel 1.x to 2.3 - Same URI must be used for both producer and consumer | |
---|---|
An exactly identical VM endpoint URI must be used for both the producer endpoint and the consumer endpoint. Otherwise Camel will create a second VM endpoint, even thought 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 it is the queue name that must match—for
example, the preceding example uses |
See the Seda component for options and other important usage as the same rules applies for this Vm component.
In the route below we send the exchange to the VM queue that is working across CamelContext instances:
from("direct:in").bean(MyOrderBean.class).to("vm:order.email");
And then in another Camel context such as deployed as in another
.war
application:
from("vm:order.email").bean(MyOrderEmailSender.class);
See also:
Seda