Return-Path: Delivered-To: apmail-activemq-camel-dev-archive@locus.apache.org Received: (qmail 37000 invoked from network); 11 Jun 2007 19:10:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 11 Jun 2007 19:10:15 -0000 Received: (qmail 58331 invoked by uid 500); 11 Jun 2007 19:09:58 -0000 Delivered-To: apmail-activemq-camel-dev-archive@activemq.apache.org Received: (qmail 58310 invoked by uid 500); 11 Jun 2007 19:09:58 -0000 Mailing-List: contact camel-dev-help@activemq.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: camel-dev@activemq.apache.org Delivered-To: mailing list camel-dev@activemq.apache.org Received: (qmail 58245 invoked by uid 99); 11 Jun 2007 19:09:58 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 12:09:58 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Jun 2007 12:09:53 -0700 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 16BAB7141FB for ; Mon, 11 Jun 2007 12:09:33 -0700 (PDT) Message-ID: <2823795.1181588973088.JavaMail.jira@brutus> Date: Mon, 11 Jun 2007 12:09:33 -0700 (PDT) From: "Noah Nordrum (JIRA)" To: camel-dev@activemq.apache.org Subject: [jira] Created: (CAMEL-14) add ability to pool routes/steps for parallel processing MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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.