camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From slew <>
Subject Re: Deploying to the same camel context
Date Fri, 06 Aug 2010 12:59:54 GMT


Thanks for the fast response.

I'm using smx 3.3.2 and camel 2.3.

I think I understand, just in case I'll repeat what I think you are
advising. Currently my components are chained using vm, but if I change to
using jbi for chaining, because there is already a thread pool in smx, the
problem goes away.

Obvious now you tell me!  I'll give it a try.

Thanks again,

Willem.Jiang wrote:
> Hi slew,
> Which version of Servicemix are you using?
> What kind of component which are you using?
> If you are using Camel JBI component, you can chain the different JBI 
> endpoints (which is deployed into ServiceMix) together by using Camel 
> route (it could be your routing slip).
> As each ServiceMix components has their own thread pool, so I don't 
> think you will get into trouble the performance bottleneck.
> Willem
> slew wrote:
>> Hi all
>> I'm running camel routes from servicemix.  This question relates to both
>> camel and servicemix, so please let me know if I should repost to the
>> servicemix forum instead.
>> I have a question about whether it's possible to deploy camel routes
>> defined
>> in separate service assemblies to the same camel context.
>> For the system I'm working on, depending on the service invoked a
>> configurable routing slip is executed.
>> The steps in the routing slip are resolved at runtime, allowing the route
>> to
>> be adjusted easily, i.e. exactly the purpose of a routing slip.
>> The routing slip steps are packaged as a jbi service assembly containing
>> a
>> camel service unit.  The routing slip is invoked from a separate service
>> assembly.  So for example someone might create an audit trail extension,
>> package it up in a sa, deploy it to servicemix and then start using it in
>> the routing slips for the services that require it.
>> Because these components are in different camel contexts, messages are
>> currently exchanged using the vm component.
>> The advantage of this approach is that these extensions are stand-alone
>> and
>> so can be created without editing anything else in the system.  They can
>> be
>> deployed, undeployed or replaced very easily.
>> The big disadvantage, and the reason for my post is that each extension
>> must
>> be configured to have enough concurrent consumers to not caues a
>> bottleneck,
>> e.g. worst case is if there could be x routing slips executed at once
>> each
>> extension should have up to x concurrent consumers.  As the system grows
>> there could be hundreds of deployed extensions all with their own thread
>> pool of concurrent consumers waiting for something to happen.  If these
>> extension routes were in the same camel context, the 'direct' call would
>> solve the problem as the route would run in the same thread as the
>> caller.
>> My question is, is there a better way to package and deploy these
>> extension
>> routing slip steps.  Is there a way to deploy them to the already running
>> routing slip context?
>> Sorry if my explanation of the problem isn't clear, I'm happy to expand
>> on
>> anything.
>> Thanks,
>> Steve.

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message