You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by Quinn Stevenson <qu...@pronoia-solutions.com> on 2018/03/16 14:25:52 UTC
[DISCUSS] - Additional Configuration option for RedeliveryPolicy
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?
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <cl...@gmail.com> 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
> <qu...@pronoia-solutions.com> 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 <cl...@gmail.com> wrote:
>>>
>>> On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson
>>> <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <cl...@gmail.com> 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
>>>>> <qu...@pronoia-solutions.com> 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
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Claus Ibsen <cl...@gmail.com>.
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
<qu...@pronoia-solutions.com> 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 <cl...@gmail.com> wrote:
>>
>> On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson
>> <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <cl...@gmail.com> 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
>>>> <qu...@pronoia-solutions.com> 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
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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 <cl...@gmail.com> wrote:
>
> On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson
> <quinn@pronoia-solutions.com <ma...@pronoia-solutions.com>> 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 <cl...@gmail.com> 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
>>> <qu...@pronoia-solutions.com> 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>
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Claus Ibsen <cl...@gmail.com>.
On Fri, Mar 16, 2018 at 4:00 PM, Quinn Stevenson
<qu...@pronoia-solutions.com> 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 <cl...@gmail.com> 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
>> <qu...@pronoia-solutions.com> 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
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Quinn Stevenson <qu...@pronoia-solutions.com>.
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.
> On Mar 16, 2018, at 8:43 AM, Claus Ibsen <cl...@gmail.com> 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
> <qu...@pronoia-solutions.com> 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
Re: [DISCUSS] - Additional Configuration option for RedeliveryPolicy
Posted by Claus Ibsen <cl...@gmail.com>.
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
<qu...@pronoia-solutions.com> 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