Hi Steve, On Thu, Oct 14, 2010 at 4:05 PM, slew <sle...@googlemail.com> wrote: > > Hi, > > In our application we have a routing slip that is configured at runtime to > invoke endpoints from "plugin" camel routes (camel 2.3) that are provided in > a separate camel context. We are using smx 3, so these plugins are packaged > as separate JBI assemblies. > > I'm trying to work out the best method to communicate between these > contexts. The original way I used was with the VM component. For > performance, I had to set the concurrentConsumers property, but this has a > drawback in that the consumer threads are fixed and so as the number of > plugins increases the number of waiting threads increases. > > I've been looking at replacing this with JBI, as I'm currently using SMX3. > This has thrown up some other questions, but as we'd look to move to SMX4 at > some point (possibly soon) and JBI is not really the future of SMX, I'm > wondering if there are better alternatives.
You can use JBI in either SMX3 or SMX4 so it's a good migration path, i.e. you should be able to continue using JBI endpoints when moving to SMX4 and then you can migrate them to something else. For new stuff in SMX4 you can use the NMR component - http://camel.apache.org/nmr.html which I think might be better suited in an OSGi environment than the VM transport. And also you can always use JMS as well, probably more useful if you want to persist messages between routes to avoid losing messages. > Going back to the VM solution. The documentation has the following: > >> Be aware that adding a thread pool to a SEDA endpoint by doing something >> like: >> from("seda:stageName").thread(5).process(...) >> Can wind up with two BlockQueues: one from the SEDA endpoint, and one from >> the workqueue of the thread pool, which may not be what you want. > > I'm not sure exactly what this means, could someone explain it to me please > - really sorry if it's a thick question? I assume it's not saying there's a > potential for a dead lock, but I can't work out what else it means. Would > this be the correct approach in my scenario, i.e. so that more threads are > working when the route is busy, less when it's not? I think it's a little typo, it should be BlockingQueues, meaning that a message would first go into the SEDA BlockingQueue, then wind up in the thread pool's BlockingQueue, so would introduce a performance impact. > Is there a better solution to this cross-context connections, e.g. JMS, > ActiveMQ. I like the VM approach as it works nicely with exception > propagation. > > I'd really appreciate anyones advice on this. Please let me know if you > need me to clarify anything. > > Thanks, > Steve. > -- > View this message in context: > http://camel.465427.n5.nabble.com/Cross-context-connections-SEDA-and-BlockQueues-tp3212752p3212752.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
