Ashwin, Thank you for your response.
If I understand you right, you suggest using approaches similar to the ones below: from(uriA).filter(not(TerminatedJobPredicate)).to(uriB) or processor from(uriA).process(FilteringProcessor).to(uriB) It may not be that big of an issue for me to include filter or filtering processor statically, even though it would be nice to alter existing route definitions, be it adding/removing processors, filters or interceptors. What if I have to change my filtering logic dynamically based on varying set of criteria? Would I be able to design some compound predicate where I could add/remove predicates on-the-fly without updating route definition? If that's possible than it would be more flexible solution. My problem with filter and filtering processor approaches, just like with interceptor approach, is that I have to add filter or filtering processor to all route definitions that I want to filter. There does not seem to be a way to apply it to all route definitions with one shot. The biggest problem that I have with using filter and filtering processor I can illustrate based on example below: from(uriA).filter(not(TerminatedJobPredicate)).process(ProcessorA).process(LongRunningProcessorB).to(uriB) Let's say I terminate JOB_ID=100 while executing ProcessorA. With filter and filtering processor approach, unlike with interceptor, LongRunningProcessorB would execute and this is exactly what I'm trying to avoid. This is one of the reasons I have looked at interceptor because it would allow me to terminate LongRunningProcessorB for JOB_ID=100. So I understand your argument that my method maybe too involved and complex but I disagree that it is unnecessary :-) Ultimately, I'm trying to terminate costly processing as soon as possible. Cheers, Andre -- View this message in context: http://camel.465427.n5.nabble.com/How-to-stop-all-Exchanges-based-on-criteria-like-header-value-tp4735364p4736289.html Sent from the Camel - Users mailing list archive at Nabble.com.
