Thanks again Claus - So it sounds like the same processed I used before I could commit directly to gitbox, right? I really would like some others to review whatever changes I make to the core - I don’t want to break it :-)
The JIRA is https://issues.apache.org/jira/browse/CAMEL-12360 <https://issues.apache.org/jira/browse/CAMEL-12360> - hopefully I’ll have the PR ready sometime next week. > On Mar 16, 2018, at 11:52 AM, Claus Ibsen <[email protected]> wrote: > > Hi Quinn > > Yeah for review you can create a github PR. eg create a branch, work > on the branch, commit, and then push this branch. > then if you go on the github page for Apache Camel, it should come up > with a "create PR" button (green) which you can click. > In the PR you can request person(s) for review. But generally a PR is > sitting there and others can review / comment etc. > > > On Fri, Mar 16, 2018 at 5:11 PM, Quinn Stevenson > <[email protected]> wrote: >> 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> > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2: https://www.manning.com/ibsen2
