If vm/seda component have multipleConsumers enabled, it creates a thread pool to preconfigure MultiCastProcessor, and this processor has parallelProcessing enabled and stopOnException disabled by default. So if consuming endpoint fails to process exchange you will not know about it in the producing endpoint, so you will not be able to rollback a transaction. I suppose it something like fire-and-forget processing. The current version of camel does not support transactions in seda and vm components (as far as I know there were some plans about adding support of transactions to seda/vm). Seda/vm also uses blocking queue internally, so in case the exchange reaches the seda/vm, you will obtain another exchange (in your case from jms queue), but the previous one may not be processed.
OSGi services component in the case of multicasting behaves like multicast eip (http://camel.apache.org/multicast.html), so the user is able to configure how the consumers should be invoked, i.e. synch/asynch, in parallel or sequentially, with/without stopping on exception. For example if the exchange is sent to the following endpoint "osgi:multicast:endpointName?stopOnException=true", it will fail if any of the consumers fail, so in case of transactional route the transaction will be rolled back. Sergey > Thanks for the hint. That could be an interesting option to split up the > route while keeping the transaction. > I know we already have the vm component which should work similar. Do > you know what the differences are from a user point of view? > Christian > Am 23.05.2012 18:50, schrieb [email protected]: >> Christian, >> >> OSGi services can be used without even restarting the container or camel >> contexts. >> As by spec. invocation of OSGi service happens synchronously in the same >> thread, so there are >> no problems with transactions. >> >> You only have to publish you consumer side into the OSGi registry somehow >> (please, feel free to >> try my osgi services component, that is discussed in another thread), next >> you will only have to add >> new producing sides that will send messages to this published into the OSGi >> registry consuming side. >> >> Again, with osgi services component you can achieve this in the following >> way: >> >> Consuming side: >> from("osgi:jmsProcessor").to("doSomethingUseful"); >> >> Producing side: >> from("jms:queue1").to("osgi:jmsProcessor"); >> >> At any time later just deploy a bundle with another producing side >> from("jms:queue2").to("osgi:jmsProcessor"); >> >> Regards, >> Sergey >> >> >>> Yeah, it might be better to just have manual restarts, since they may >>> be in the middle of some db changes and the routes would be restarting >>> themselves multiple times (perhaps with half-baked config). Sounds >>> like you've got it under control. Please report back to let us know >>> how things went and so other might be able to learn from this cool >>> example! >>> On Wed, May 23, 2012 at 10:22 AM, Christian Schneider >>> <[email protected]> wrote: >>>> Yes .. that is what I intended to do. As the deployment is in OSGi I plan >>>> to >>>> use the config admin service integration in blueprint. >>>> So the bundle restarts automatically on config changes. If the config has >>>> to >>>> be in DB then I think it is good enough if the admin restarts the bundle by >>>> hand when >>>> the db changes. Changes are typically expected when deployments change. >>>> >>>> Christian >>>> >>>> >>>> Am 23.05.2012 16:04, schrieb James Carman: >>>> >>>>> Yeah, sorry, didn't understand what you were trying to do. Perhaps you >>>>> can >>>>> programmatically stop/restart your camel context at runtime based on some >>>>> sort of event (database changes?). Then, your route builder would read >>>>> the >>>>> information from the database to dynamically configure your routes? >>>>> >>>>> On May 23, 2012 9:38 AM, "Christian Schneider"<[email protected]> >>>>> wrote: >>>>> >>>>>> Topics would not help in my case. >>>>>> >>>>>> The use case here is to have kind of a generic engine that can route >>>>>> between queues with config from a db or file. >>>>>> >>>>>> Christian >>>>>> >>>>>> >>>>>> Am 23.05.2012 15:10, schrieb James Carman: >>>>>> >>>>>>> Are you in need of a topic rather than a queue? >>>>>>> >>>>>>> On Wed, May 23, 2012 at 8:13 AM, Christian Schneider >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>>> The problem is that the from endpoints are not known at compile time >>>>>>>> and >>>>>>>> can >>>>>>>> change at any time. >>>>>>>> Besides that we need transactionality. Not sure if seda provides that. >>>>>>>> Christian >>>>>>>> >>>>>>>> Am 23.05.2012 13:41, schrieb Serkan Eryilmaz: >>>>>>>> >>>>>>>>> Couldn't you just create a seda queue once (that is your logic route), >>>>>>>>> and >>>>>>>>> then for each jms queue that gets added you redirect it to that seda >>>>>>>>> queue ? >>>>>>>>> >>>>>>>>> On 05/23/2012 01:03 PM, Christian Schneider wrote: >>>>>>>>> >>>>>>>>>> I would like to listen to a list of jms queues and for each queue do >>>>>>>>>> the >>>>>>>>>> same route. >>>>>>>>>> >>>>>>>>>> Currently I use a RouteBuilder that gets the jms endpoint uri in its >>>>>>>>>> constructor and builds the route. This routebuilder is then created >>>>>>>>>> once for >>>>>>>>>> each jms endpoint and the >>>>>>>>>> route is added each time to the context. This works but I wonder if >>>>>>>>>> we >>>>>>>>>> can do this in a generic way. For the producer side we have the >>>>>>>>>> recipientlist where you can give it a list of endpoints to send to. >>>>>>>>>> >>>>>>>>>> How about a component that can create consumers from a list of uris >>>>>>>>>> separated by comma? Would there be a general interest in such a >>>>>>>>>> thing? >>>>>>>>>> Do we >>>>>>>>>> perhaps have a similar thing that I just overlooked? >>>>>>>>>> >>>>>>>>>> Christian >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> Christian Schneider >>>>>>>> http://www.liquid-reality.de >>>>>>>> >>>>>>>> Open Source Architect >>>>>>>> Talend Application Integration Division http://www.talend.com >>>>>>>> >>>>>>>> >>>>>> -- >>>>>> Christian Schneider >>>>>> http://www.liquid-reality.de >>>>>> >>>>>> Open Source Architect >>>>>> Talend Application Integration Division http://www.talend.com >>>>>> >>>>>> >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> Talend Application Integration Division http://www.talend.com >>>> >> >> -- Best regards, Sergey mailto:[email protected]
