Hi
On Fri, Mar 5, 2010 at 12:12 AM, Alexandros Karypidis <[email protected]> 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
