Return-Path: X-Original-To: apmail-camel-users-archive@www.apache.org Delivered-To: apmail-camel-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 39847DA24 for ; Thu, 13 Sep 2012 07:07:40 +0000 (UTC) Received: (qmail 58760 invoked by uid 500); 13 Sep 2012 07:07:39 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 58672 invoked by uid 500); 13 Sep 2012 07:07:39 -0000 Mailing-List: contact users-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@camel.apache.org Delivered-To: mailing list users@camel.apache.org Delivered-To: moderator for users@camel.apache.org Received: (qmail 51471 invoked by uid 99); 13 Sep 2012 07:05:24 -0000 X-ASF-Spam-Status: No, hits=4.2 required=5.0 tests=HTML_MESSAGE,SPF_NEUTRAL,URI_HEX X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 216.139.236.26 is neither permitted nor denied by domain of jimbogaz@gmail.com) Date: Thu, 13 Sep 2012 00:04:58 -0700 (PDT) From: jimbogaz To: users@camel.apache.org Message-ID: In-Reply-To: References: <1347482245310-5719208.post@n5.nabble.com> Subject: Re: Multicast, redelivery and error handlers MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_28510_29834152.1347519898173" ------=_Part_28510_29834152.1347519898173 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Thanks for the fast response Claus. I figured that must have been the case, which is why I then tried implementing the timeout method on a TimeoutAwareAggregator. I thought if I called setException there (just with a plain new Exception) then that might trigger the error handler. I should describe that what I want to happen is that either the whole multicast tries again, or perhaps just the one that timed out. Is there a different way of achieving that? Thanks again, James On Sep 13, 2012 8:43 AM, "Claus Ibsen-2 [via Camel]" < ml-node+s465427n5719232h22@n5.nabble.com> wrote: > There is no exception occurring. And therefore the error handler does > not redeliver anything. > If the timeout is hit on the multicast, then yes the multicast will > aggregate what it currently has, and continue routing. > > > > On Wed, Sep 12, 2012 at 10:37 PM, jimbogaz <[hidden email]> > wrote: > > > Hi all. > > > > I think I'm missing something obvious, but I can't find anything here > that > > is similar to my problem, or any docs that tell me "it's obvious James > you > > twerp": > > > > I've put together a route that multicasts to three direct routes, which > > simply return setBody type responses. I have intentionally made one of > them > > take longer than the timeout on the multicast, with the intention that > the > > error handler retries the request. It doesn't. I have tried with both > > having a TimeoutAwareAggregationStrategy with a setException (which I > > thought would automatically invoke the error handler), and with just a > plain > > AggregationStrategy. > > > > I'm on Camel 2.9.3, and below are my (sanitised to protect my client) > > sections from beans.xml and my main method... can anybody tell me where > I'm > > epic failing? > > > > > > public static void main(String... args) throws Exception { > > ApplicationContext appContext = new > > ClassPathXmlApplicationContext("beans.xml"); > > LOG.info("Initialised Application Context"); > > CamelContext camelContext = appContext.getBean("camel-context", > > CamelContext.class); > > ProducerTemplate producerTemplate = > > camelContext.createProducerTemplate(); > > producerTemplate.asyncCallbackRequestBody("direct:blah", > > "James[hidden email]", > callback); > > Thread.sleep(15000); > > LOG.info("FINISHED"); > > } > > > > > xmlns="http://camel.apache.org/schema/spring"> > > com.rightmess.camel > > > > > > > retryAttemptedLogLevel="WARN" redeliveryDelay="200"/> > > > > > > > > > parallelProcessing="true" streaming="true" > timeout="700"> > > > > > > > > > > > > > > > > 233 > > > > > 15/04/1868 > > > > > > > > 1500 > > > > > Starbucks > > > > > > > > > > 233 > > > > > 0982734786238746 > > > > > > > > > > > > > > > > > -- > > View this message in context: > http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [hidden email] > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719232.html > To unsubscribe from Multicast, redelivery and error handlers, click here > . > NAML > -- View this message in context: http://camel.465427.n5.nabble.com/Multicast-redelivery-and-error-handlers-tp5719208p5719236.html Sent from the Camel - Users mailing list archive at Nabble.com. ------=_Part_28510_29834152.1347519898173--