camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: VM component behaviour
Date Fri, 05 Mar 2010 06:00:14 GMT

On Fri, Mar 5, 2010 at 12:12 AM, Alexandros Karypidis <> wrote:
> Hello,
> I have some questions regarding the VM (
> component. So, just to make sure I understand the docs correctly:
> 1) Even though VM channels live at the "JVM level", they still need to be
> associated with a CamelContext. So, if no CamelContext referencing the
> channel exists, the channel is destroyed and any in-flight messages are
> discared. (For example, assume you are using it in a web container for
> communication across 2 WARs; undeploying BOTH of them results in the VM
> channel to be destroyed and any messages inside it to be discarded).

Its a cheap way of sharing between multple WAR files with the cost of
having camel-core in the bootstrap classloader.
So they should only be destroyed when your shutdown the web container.

> 2) Even though it does not provide persistence, it is also reliable in that
> it doesn't "drop" messages. So, if something makes it into the queue, it
> will come out on the other side (unless of course the channel is destroyed
> as per case (1) above). Correct?

Yeah its build on top of SEDA so its using a Queue from the JDK core
to hold messages.

In the future we may add support for persistence using HawtDB

> 3) The docs say that setting the "waitForTaskToComplete" flag
> ( causes the behaviour: "the caller should
> wait for the async task to complete or not before continuing". Who is the
> "caller" in this context? The thread submitting a message to the queue? So,
> setting this flag means that posting a message to the queue would block the
> thread that posted it until the message is retrieved and processed on the
> other side?

The caller is whoever sends the message to the queue. You can use
either InOnly or InOut MEP.
For InOut the caller should wait for a reply. You can control this
behavior with that option.

> 4) Is it possible to specify a TTL per message posted in the VM queue? So,
> if a message arrives to late at the consumer it will be dropped? My
> understanding is that the "timeout" parameter refers to the time spent while
> processing a message at the consumer side and not for the time the message
> can exist in the queue.

No but you can provide your own BlockingQueue impl which have timeout support.
I recon the JDK may already have such one. Or its not that hard to create one.

But feel free to create such an implementation and add a JIRA ticket,
then we can have that supported in the future in Camel.

> 5) Suppose "multipleConsumers" is true; how does the "concurrentConsumers"
> parameter affect each consumer? Will I have "concurrentConsumers x
> number_of_receiving_endpoints" threads working on processing messages?

No multipleConsumers is if you have 2+ <from> the VM queue.
Normally you only have 1 <from> consumer.

And if you have Camel uses multicast to send the same message to the
multiple consumers.

> Thank you in advance.

Claus Ibsen
Apache Camel Committer

Author of Camel in Action:
Open Source Integration:

View raw message