You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Noah Nordrum (JIRA)" <ji...@apache.org> on 2007/06/11 21:09:33 UTC
[jira] Created: (CAMEL-14) add ability to pool routes/steps for
parallel processing
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: core
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:
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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hiram Chirino updated CAMEL-14:
-------------------------------
Affects Version/s: 1.1
> 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:
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44850#action_44850 ]
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 ThreadType.java) for instance it has a max size property:
private Integer maxSize = 1;
Can't you just append the options using the fluent builder?
{code}
from("activemq:queue:SOMETHING").thread(5).setMaxSize(15).process(new ExpensiveMessageEnricher()).to("activemq:queue:SOMEWHERE_ELSE");
{code}
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: https://issues.apache.org/activemq/browse/CAMEL-14
> 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.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "James Strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Strachan updated CAMEL-14:
--------------------------------
Fix Version/s: (was: 1.2.0)
1.3.0
> 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
> Reporter: Noah Nordrum
> Fix For: 1.3.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.
[jira] Resolved: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen resolved CAMEL-14.
------------------------------
Fix Version/s: 1.2.0
(was: 2.0.0)
Resolution: Duplicate
> 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
> Reporter: Noah Nordrum
> Fix For: 1.2.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.
[jira] Commented: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Charles Moulliard (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44831#action_44831 ]
Charles Moulliard commented on CAMEL-14:
----------------------------------------
Be careful, what you propose (pool(5,15)) can generate confusion in the head of the users because actually, you can define the number of thread that you want :
from("activemq:queue:SOMETHING").thread(5).process(new ExpensiveMessageEnricher()).to("activemq:queue:SOMEWHERE_ELSE");
Personally, what you request already exist except that we cannot now define the limit of the thread to be created.
If you want to process tasks in // (parallel), you can use the multicast EIP (http://activemq.apache.org/camel/multicast.html).
> 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
> 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.
[jira] Commented: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44852#action_44852 ]
Claus Ibsen commented on CAMEL-14:
----------------------------------
Implemented by CAMEL-149. Closing this one.
> 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
> 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.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hiram Chirino updated CAMEL-14:
-------------------------------
Affects Version/s: (was: 1.1)
Fix Version/s: 1.1
> 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
> Reporter: Noah Nordrum
> Assignee: James Strachan
> Fix For: 1.1
>
>
> 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.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "James Strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Strachan updated CAMEL-14:
--------------------------------
Fix Version/s: (was: 1.1.0)
1.2.0
> 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
> Reporter: Noah Nordrum
> Fix For: 1.2.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.
[jira] Commented: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=44851#action_44851 ]
Claus Ibsen commented on CAMEL-14:
----------------------------------
Ah it got fluent builders already so you should use
{code}
thread(5).maxSize(15)
{code}
> 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
> 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.
[jira] Updated: (CAMEL-14) add ability to pool routes/steps for
parallel processing
Posted by "James Strachan (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/CAMEL-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
James Strachan updated CAMEL-14:
--------------------------------
Assignee: (was: James Strachan)
> 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
> Reporter: Noah Nordrum
> Fix For: 1.1
>
>
> 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.