[
https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino updated CAMEL-14:
-------------------------------
Description:
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
was:
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:
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");
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
> add ability to pool routes/steps for parallel processing
> --------------------------------------------------------
>
> Key: CAMEL-14
> URL: https://issues.apache.org/activemq/browse/CAMEL-14
> Project: Apache Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: 1.1
> Reporter: Noah Nordrum
> Assignee: James Strachan
>
> 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.
