camel-users mailing list archives

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


On Fri, Mar 5, 2010 at 12:12 AM, Alexandros Karypidis <akarypid@yahoo.gr> wrote:
> Hello,
>
> I have some questions regarding the VM (http://camel.apache.org/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
http://davsclaus.blogspot.com/2010/03/apache-camel-23-overhauled-aggregator.html


> 3) The docs say that setting the "waitForTaskToComplete" flag
> (http://camel.apache.org/seda.html) 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: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus

Mime
View raw message