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 60FC3FC9B for ; Sat, 27 Apr 2013 05:29:37 +0000 (UTC) Received: (qmail 73066 invoked by uid 500); 27 Apr 2013 05:29:37 -0000 Delivered-To: apmail-camel-users-archive@camel.apache.org Received: (qmail 72619 invoked by uid 500); 27 Apr 2013 05:29:33 -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 24859 invoked by uid 99); 26 Apr 2013 16:33:51 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of sven@ast.dfs.de designates 194.49.178.254 as permitted sender) Message-ID: <517AAC54.1000700@ast.dfs.de> Date: Fri, 26 Apr 2013 18:33:24 +0200 From: Sven Bauhan User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: users@camel.apache.org Subject: Re: AggregationStrategy and wrong sequence order References: <517A85D4.5080300@ast.dfs.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at ast.dfs.de X-Virus-Checked: Checked by ClamAV on apache.org Ok, but then the timeout for the aggregation can occur, if the sender does not resend the message fast enough. The only solution I found is to set the predicate to true, if an error occured. Then the exception will be thrown in the onCompletion() method of the AggregationStrategy. So the message is complete for the Aggregator. But then I have to implement the closeCorrelationKeyOnCompletion Cache on my own. Better would be if there was a discardOnFailure() method for aggregate() in the route similar to discardOnCompletionTimeout(). Sven On 04/26/13 16:46, Claus Ibsen wrote: > Hi > > You can just store some state on the oldExchange before throwing that > exception in the aggregate method. > So the next time, you can find that state on oldExchange and then > regard it as "null". > > > > On Fri, Apr 26, 2013 at 3:49 PM, Sven Bauhan wrote: >> Hi, >> >> I try to implement a fault handling in my AggregationStrategy for missing >> segments or a wrong sequence order. >> >> The standard for my protocol says, when the segments are not received in >> correct order, the receiver shall send an error response and withdraw all >> previously received segments of the message. The sender will send the >> complete message again on error response. >> >> In the method aggregate(Exchange oldExchange, Exchange newExchange) I throw >> an exception. This is caught in the route and an error response is sent >> back. But with the next segment, the oldExchange is unchanged. >> >> What I would expect is that the aggregator discards all messages previously >> received for this correlation key. So the next segment received would have >> an oldExchange=null. >> >> Is it possible to make the aggregator act this way? how can I implement >> this? >> >> Thanks, Sven >> > >