Deploying to the same camel context

[slew <sl...@googlemail.com>]

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: http://camel.465427.n5.nabble.com/Deploying-to-the-same-camel-context-tp2266422p2266422.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Deploying to the same camel context

[slew <sl...@googlemail.com>]

Hi,

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,
Steve.


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: http://camel.465427.n5.nabble.com/Deploying-to-the-same-camel-context-tp2266422p2266587.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Deploying to the same camel context

[Willem Jiang <wi...@gmail.com>]

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.