On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson <[email protected]> wrote: > Thanks Claus - > > Does that mean you think it would be a worthwhile addition to Camel? If so, > I’ll create the JIRA. > > I’d like it because I’ve basically had to reproduce a good portion of what > Camel already does (logging the redelivery) just to eliminate some log > entries (to keep our Splunk usage down), and I’d rather let Camel do it. >
Yeah I think its a worth-while addition. Its a use-case from the real-world, and not something, lets say, I imagined and just added "because I can". Having good visibility into what Camel is doing is important IMHO. Its a bit complex when you deal with errors and the error handling in Camel in general. Mind that setting redelivery options in camel-core is done in a fair number of places to get it into both the Java and XML dsl in the right places. So you can maybe take a look at where one of the other option is currently in use and then copy that. > >> On Mar 16, 2018, at 8:43 AM, Claus Ibsen <[email protected]> wrote: >> >> Hi >> >> Yeah naming is hard. Some of the bits in camel uses "interval" or >> "frequent" for something that triggers every X >> >> logRetryAttemptedInterval >> >> or >> >> logRetryAttemptedFrequency >> >> >> >> >> On Fri, Mar 16, 2018 at 3:25 PM, Quinn Stevenson >> <[email protected]> wrote: >>> I have a pretty common pattern in the redelivery pattern in my routes, and >>> it would be nice if the RedeliveryPolicy supported it directly. I was >>> going to create a JIRA for it, but I wanted to get some feedback to see if >>> others felt it would be a useful/worthwhile addition. >>> >>> When I setup redelivery for my routes, I’m often setting them up to “retry >>> forever” so I don’t drop messages if destinations are down - nothing >>> special here. However, the external systems are often down for extended >>> periods of time so I can wind up with a LOT of log messages for the retry >>> attempts. I want some of the retry attempts logged so I know the >>> redelivery attempt is going on, but I don’t need the log message every >>> 15-sec. >>> >>> I have tried bigger values maximumRedeliveryDelay, but then I get in >>> situations where the route can take a very long time to stop (waiting for >>> that pending redelivery delay). >>> >>> To address this issue, I set logRetryAttempted to false in the redelivery >>> policy, and then use an onRedelivery processor to log the redelivery >>> attempts I’m interested in. After messing with this for a while, I’ve >>> discovery the most common configuration I use is to log the first >>> redelivery attempt, and the every n-th attempt, where n can be configured. >>> >>> My proposal is to add a configuration option to the redeliveryPolicy so it >>> supports this directly. I haven’t come up with a very good name for the >>> option - logRetryAttemptedModulus is the only thing that popped into my >>> head and I don’t like it much. >>> >>> Does anyone have any feedback on this proposal? And an idea for a good >>> name for the option? >>> >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
