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.
