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.
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?
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.
