camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen (JIRA)" <>
Subject [jira] Commented: (CAMEL-14) add ability to pool routes/steps for parallel processing
Date Fri, 08 Aug 2008 12:20:52 GMT


Claus Ibsen commented on CAMEL-14:

Yes as Charles said there is a thread() DSL type that can be used for thread pool.

It has attributes you can configure (see for instance it has a max size property:
 private Integer maxSize = 1;

Can't you just append the options using the fluent builder?

from("activemq:queue:SOMETHING").thread(5).setMaxSize(15).process(new ExpensiveMessageEnricher()).to("activemq:queue:SOMEWHERE_ELSE");

I think thus we already have this feature in Camel 1.4

> add ability to pool routes/steps for parallel processing
> --------------------------------------------------------
>                 Key: CAMEL-14
>                 URL:
>             Project: Apache Camel
>          Issue Type: New Feature
>          Components: camel-core
>            Reporter: Noah Nordrum
>             Fix For: 2.0.0
> If you have a route that goes through a processor that is expensive, you may want to
pool that processor so it's not holding up the rest of the route.
> Configuration could look as such:
> {code:java}
> from("activemq:queue:SOMETHING").pool(5 [min], 15 [max]).process(new ExpensiveMessageEnricher()).to("activemq:queue:SOMEWHERE_ELSE");
> or
> from("activemq:queue:SOMETHING").process(new ExpensiveMessageEnricher()).pool(5 [min],
15 [max]).to("activemq:queue:SOMEWHERE_ELSE");
> {code}
> I'm not sure exactly how these would differ, but I think the first one would have 5-15
MQ queue listeners, which would all go through 1 EME, and then through 1 mq producer, and
the second would have 1 mq listener that would dispatch to one of the 5-15 EME threads (if
available?, not sure if that level of interaction between steps is good), and then go through
1 mq producer.
> Seems like the first would be the better option as I write this...
> Notes from IRC convo with James:
> first thought is; we might wanna wrap a Producer in a factory thingy that does pooling
(e.g. like the way spring does pooling using interceptors etc); but that the pool part could
be done wherever a Processor can be used

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message