OK - I’ll get the JIRA opened. Thank you for the tips on implementing this.
One question - where can I find the procedure to request a review of the change? Do I just work in my fork on GitHub and then make a PR? Or is there a different process for committers? > On Mar 16, 2018, at 10:06 AM, Claus Ibsen <[email protected]> wrote: > > On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson > <[email protected] <mailto:[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 <http://davsclaus.com/> @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2 > <https://www.manning.com/ibsen2>
