Hi Yeah that may be possible. Feel free to log a JIRA ticket.
On Fri, Apr 26, 2013 at 6:33 PM, Sven Bauhan <[email protected]> wrote: > 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 <[email protected]> >> 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 >>> >> >> > -- Claus Ibsen ----------------- Red Hat, Inc. FuseSource is now part of Red Hat Email: [email protected] Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
