date:20240202

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

2024-02-02 Thread Andrea Cosentino

This is how you can unsubscribe. In the way you've done it won't work.

https://camel.apache.org/community/mailing-list/

Il giorno ven 2 feb 2024 alle ore 14:25 George Daswani <
georgedasw...@hotmail.com> ha scritto:

> unsubscribe
>
> On Fri, Feb 2, 2024 at 2:29 AM Jono Morris  wrote:
>
> >
> > The Throttler previously employed a fixed windows algorithm, allowing a
> > fixed number of calls in a particular period. This is susceptible to
> > request bursts, e.g. for a limit of 100 requests/hour, all 100 requests
> > might be made in the first minute.
> >
> > Subsequently the algorithm was changed to a leaky bucket implementation.
> > Callers try to acquire a permit and block if all the available permits
> have
> > already been acquired. Permits are released after a caller completes
> > processing.  So this limits the number of concurrent requests.
> >
> > Will discuss with the team to find the best way forward.
> >
> > Regards
> > Jono
> >
> > On 2024/02/01 16:49:14 Otavio Rodolfo Piske wrote:
> > > Hello,
> > >
> > > Quite frankly, I don't know.
> > >
> > > However, I did raise this question on the PR that introduced the change
> > so
> > > we can discuss how we can improve the documentation for scenarios such
> as
> > > the one you raised.
> > >
> > > Kind regards
> > >
> > > On Wed, Jan 31, 2024 at 4:05 PM Schmeier, Jannik <
> j.schme...@fraport.de>
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > I'm wondering why the timePeriodMillis option has been removed for
> the
> > > > throttle EIP.
> > > >
> > > > I have an endpoint that can only receive about 5 requests per minute,
> > else
> > > > the request will fail. I accounted for that by using a
> timePeriodMillis
> > > > setting of 6 ms and a throttle value of 4.
> > > > Now with the updated Throttle EIP I can't do that anymore.
> > > >
> > > > The upgrade guide suggests that the default time period is 1000 ms
> now,
> > > > but obviously I can't work with that:
> > > >
> >
> https://camel.apache.org/manual/camel-4x-upgrade-guide-4_3.html#_throttle_eip
> > > >
> > > > Any suggestions?
> > > >
> > > > Best regards
> > > >
> > >
> > >
> > > --
> > > Otavio R. Piske
> > > http://orpiske.net
> > >
> >
>

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

2024-02-02 Thread George Daswani

unsubscribe

On Fri, Feb 2, 2024 at 2:29 AM Jono Morris  wrote:

>
> The Throttler previously employed a fixed windows algorithm, allowing a
> fixed number of calls in a particular period. This is susceptible to
> request bursts, e.g. for a limit of 100 requests/hour, all 100 requests
> might be made in the first minute.
>
> Subsequently the algorithm was changed to a leaky bucket implementation.
> Callers try to acquire a permit and block if all the available permits have
> already been acquired. Permits are released after a caller completes
> processing.  So this limits the number of concurrent requests.
>
> Will discuss with the team to find the best way forward.
>
> Regards
> Jono
>
> On 2024/02/01 16:49:14 Otavio Rodolfo Piske wrote:
> > Hello,
> >
> > Quite frankly, I don't know.
> >
> > However, I did raise this question on the PR that introduced the change
> so
> > we can discuss how we can improve the documentation for scenarios such as
> > the one you raised.
> >
> > Kind regards
> >
> > On Wed, Jan 31, 2024 at 4:05 PM Schmeier, Jannik 
> > wrote:
> >
> > > Hello,
> > >
> > > I'm wondering why the timePeriodMillis option has been removed for the
> > > throttle EIP.
> > >
> > > I have an endpoint that can only receive about 5 requests per minute,
> else
> > > the request will fail. I accounted for that by using a timePeriodMillis
> > > setting of 6 ms and a throttle value of 4.
> > > Now with the updated Throttle EIP I can't do that anymore.
> > >
> > > The upgrade guide suggests that the default time period is 1000 ms now,
> > > but obviously I can't work with that:
> > >
> https://camel.apache.org/manual/camel-4x-upgrade-guide-4_3.html#_throttle_eip
> > >
> > > Any suggestions?
> > >
> > > Best regards
> > >
> >
> >
> > --
> > Otavio R. Piske
> > http://orpiske.net
> >
>

Re: How to make Camel cloud cron "friendly"

2024-02-02 Thread Luca Burgazzoli

We have a camel-k-runtime module [1] to support camel-k to automatically
create a Kubernetes CronJob which does something similar.
There is also the camel.main.durationMaxMessages option on camel-main [2]
that can be configure to shut down the context after a bumber of messages
so if configured to 1 and assuming that the first exchange is only a
trigger, then it should be enough to achieve the goal (if not, we cna add
additional options to make camel-main taking care of shutting down the
context according to some rules).

[1] https://github.com/apache/camel-k-runtime/tree/main/camel-k-cron
[2] https://camel.apache.org/components/4.0.x/others/main.html

---
Luca Burgazzoli


On Fri, Feb 2, 2024 at 11:38 AM Pasquale Congiusti <
pasquale.congiu...@gmail.com> wrote:

>
>
> On Fri, Feb 2, 2024 at 11:17 AM Maarten Donderwinkel
>  wrote:
>
>> We run a couple of Camel applications that utilize a K8S Cronjob.
>>
>>
>>
>> For our case we can auto shutdown the application with the property
>> camel.main.durationMaxIdleSeconds.
>>
>> It’ll shutdown if the application is idle for a number of seconds.
>>
>> Your use-case and desired ‘trigger’ might be different of course, but
>> there are more options to auto shutdown
>>
>>
>>
>> See https://camel.apache.org/components/4.0.x/others/main.html for more
>> information on that property and how to set it.
>>
>
> Thanks Maarten, it could be an interesting approach. Wasn't aware of those
> configuration. I'll experiment with them as well.
>
>
>>
>>
>> Met vriendelijke groet | Kind Regards | Meilleures salutations | Mit
>> freundlichen Grüβen,
>>
>> Maarten Donderwinkel
>>
>> Aiden Locatie Den Bosch [image: Email] maarten.donderwin...@aiden.eu
>> www.aiden.eu
>>   Het
>> Zuiderkruis 61
>> 5215 MV 's-Hertogenbosch
>>  +31 (0) 88 060 5111
>>
>>  +31 (0) 6 8683 0832
>>
>> [image: facebook.png]  [image:
>> linkedin.png]  [image:
>> Twitter]  [image: youtube]
>> 
>> 
>> 
>> 
>> 
>> 
>>
>>
>> *From: *Pasquale Congiusti 
>> *Date: *Friday, 2 February 2024 at 11:08
>> *To: *dev , users@camel.apache.org <
>> users@camel.apache.org>
>> *Subject: *How to make Camel cloud cron "friendly"
>>
>> Hi folks,
>> I'm working lately on some experiment to run a generic Camel application
>> on
>> a Kubernetes CronJob. The behavior expected by the cluster is that, once
>> the job workload is over, the application would exit with either a success
>> or error code. As we're running a Camel application, although the route
>> may
>> have finished, the entire application will continue to run until a
>> forceful
>> shutdown. I am not sure it exists any other way, so I found my way to
>> workaround this behavior by following the approach in [1], which would
>> ends
>> up in something like the following code:
>>
>> public class TestCron extends RouteBuilder {
>> @Override
>> public void configure() throws Exception {
>> from("timer:cron?delay=0=1=1")
>> // Simulate heavylift work
>> .delay(1)
>> .to("log:info")
>> .log("DONE!")
>> .process(new Processor() {
>> Thread stop;
>> @Override
>> public void process(final Exchange exchange) throws Exception
>> {
>> if (stop == null) {
>> stop = new Thread() {
>> @Override
>> public void run() {
>> try {
>> exchange.getContext().stop();
>> } catch (Exception e) {
>> // ignore
>> }
>> }
>> };
>> }
>> // start the thread that stops the context
>> stop.start();
>> }
>> });
>> }
>> }
>>
>> However, this workaround feels a bit too hacky as it involves playing with
>> Camel Context directly. It is also impossible to reproduce easily in non
>> Java DSL, like in YAML. I am wondering if we can think on having a higher
>> level EIP such we have with "stop", something like "shutdown" which
>> behavior may be similar of what described above, taking care to gracefully
>> shutdown the application when it is invoked. This one may do some finer
>> grained controls to verify that the exchanges has really completed or
>> there
>> are no others routes running or any other low level check that would
>> perform a controlled shutdown. How does it sound? or which would be any
>>

Re: How to make Camel cloud cron "friendly"

2024-02-02 Thread Pasquale Congiusti

On Fri, Feb 2, 2024 at 11:17 AM Maarten Donderwinkel
 wrote:

> We run a couple of Camel applications that utilize a K8S Cronjob.
>
>
>
> For our case we can auto shutdown the application with the property
> camel.main.durationMaxIdleSeconds.
>
> It’ll shutdown if the application is idle for a number of seconds.
>
> Your use-case and desired ‘trigger’ might be different of course, but
> there are more options to auto shutdown
>
>
>
> See https://camel.apache.org/components/4.0.x/others/main.html for more
> information on that property and how to set it.
>

Thanks Maarten, it could be an interesting approach. Wasn't aware of those
configuration. I'll experiment with them as well.


>
>
> Met vriendelijke groet | Kind Regards | Meilleures salutations | Mit
> freundlichen Grüβen,
>
> Maarten Donderwinkel
>
> Aiden Locatie Den Bosch [image: Email] maarten.donderwin...@aiden.eu
> www.aiden.eu
>   Het
> Zuiderkruis 61
> 5215 MV 's-Hertogenbosch
>  +31 (0) 88 060 5111
>
>  +31 (0) 6 8683 0832
>
> [image: facebook.png]  [image:
> linkedin.png]  [image: Twitter]
>  [image: youtube]
> 
> 
> 
> 
> 
> 
>
>
> *From: *Pasquale Congiusti 
> *Date: *Friday, 2 February 2024 at 11:08
> *To: *dev , users@camel.apache.org <
> users@camel.apache.org>
> *Subject: *How to make Camel cloud cron "friendly"
>
> Hi folks,
> I'm working lately on some experiment to run a generic Camel application on
> a Kubernetes CronJob. The behavior expected by the cluster is that, once
> the job workload is over, the application would exit with either a success
> or error code. As we're running a Camel application, although the route may
> have finished, the entire application will continue to run until a forceful
> shutdown. I am not sure it exists any other way, so I found my way to
> workaround this behavior by following the approach in [1], which would ends
> up in something like the following code:
>
> public class TestCron extends RouteBuilder {
> @Override
> public void configure() throws Exception {
> from("timer:cron?delay=0=1=1")
> // Simulate heavylift work
> .delay(1)
> .to("log:info")
> .log("DONE!")
> .process(new Processor() {
> Thread stop;
> @Override
> public void process(final Exchange exchange) throws Exception {
> if (stop == null) {
> stop = new Thread() {
> @Override
> public void run() {
> try {
> exchange.getContext().stop();
> } catch (Exception e) {
> // ignore
> }
> }
> };
> }
> // start the thread that stops the context
> stop.start();
> }
> });
> }
> }
>
> However, this workaround feels a bit too hacky as it involves playing with
> Camel Context directly. It is also impossible to reproduce easily in non
> Java DSL, like in YAML. I am wondering if we can think on having a higher
> level EIP such we have with "stop", something like "shutdown" which
> behavior may be similar of what described above, taking care to gracefully
> shutdown the application when it is invoked. This one may do some finer
> grained controls to verify that the exchanges has really completed or there
> are no others routes running or any other low level check that would
> perform a controlled shutdown. How does it sound? or which would be any
> alternative to make Camel more cloud cron "friendly"?
>
> Regards,
> Pasquale.
>
> [1]
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcamel.apache.org%2Fmanual%2Ffaq%2Fhow-can-i-stop-a-route-from-a-route.html%23HowcanIstoparoutefromaroute-Usingathreadtostoparoutefromaroute=05%7C02%7Cmaarten.donderwinkel%40aiden.eu%7C9549aaebd583438beb6608dc23d6d5dc%7Cb9d83e0e2e894f4e9c2bbe3df185e1af%7C0%7C0%7C638424652819450381%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Gbf%2F8vAkywA7et%2FBR12uqs1OqTNFeP7Saaqm6jJHCzg%3D=0
> 
>

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

2024-02-02 Thread ski n

Maybe check the following Jira issue I created and post your use case and
concerns there:

https://issues.apache.org/jira/browse/CAMEL-20355

Raymond


On Fri, Feb 2, 2024 at 11:29 AM Jono Morris  wrote:

>
> The Throttler previously employed a fixed windows algorithm, allowing a
> fixed number of calls in a particular period. This is susceptible to
> request bursts, e.g. for a limit of 100 requests/hour, all 100 requests
> might be made in the first minute.
>
> Subsequently the algorithm was changed to a leaky bucket implementation.
> Callers try to acquire a permit and block if all the available permits have
> already been acquired. Permits are released after a caller completes
> processing.  So this limits the number of concurrent requests.
>
> Will discuss with the team to find the best way forward.
>
> Regards
> Jono
>
> On 2024/02/01 16:49:14 Otavio Rodolfo Piske wrote:
> > Hello,
> >
> > Quite frankly, I don't know.
> >
> > However, I did raise this question on the PR that introduced the change
> so
> > we can discuss how we can improve the documentation for scenarios such as
> > the one you raised.
> >
> > Kind regards
> >
> > On Wed, Jan 31, 2024 at 4:05 PM Schmeier, Jannik 
> > wrote:
> >
> > > Hello,
> > >
> > > I'm wondering why the timePeriodMillis option has been removed for the
> > > throttle EIP.
> > >
> > > I have an endpoint that can only receive about 5 requests per minute,
> else
> > > the request will fail. I accounted for that by using a timePeriodMillis
> > > setting of 6 ms and a throttle value of 4.
> > > Now with the updated Throttle EIP I can't do that anymore.
> > >
> > > The upgrade guide suggests that the default time period is 1000 ms now,
> > > but obviously I can't work with that:
> > >
> https://camel.apache.org/manual/camel-4x-upgrade-guide-4_3.html#_throttle_eip
> > >
> > > Any suggestions?
> > >
> > > Best regards
> > >
> >
> >
> > --
> > Otavio R. Piske
> > http://orpiske.net
> >
>

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

2024-02-02 Thread Jono Morris

The Throttler previously employed a fixed windows algorithm, allowing a fixed 
number of calls in a particular period. This is susceptible to request bursts, 
e.g. for a limit of 100 requests/hour, all 100 requests might be made in the 
first minute.

Subsequently the algorithm was changed to a leaky bucket implementation.  
Callers try to acquire a permit and block if all the available permits have 
already been acquired. Permits are released after a caller completes 
processing.  So this limits the number of concurrent requests. 

Will discuss with the team to find the best way forward.

Regards
Jono

On 2024/02/01 16:49:14 Otavio Rodolfo Piske wrote:
> Hello,
> 
> Quite frankly, I don't know.
> 
> However, I did raise this question on the PR that introduced the change so
> we can discuss how we can improve the documentation for scenarios such as
> the one you raised.
> 
> Kind regards
> 
> On Wed, Jan 31, 2024 at 4:05 PM Schmeier, Jannik 
> wrote:
> 
> > Hello,
> >
> > I'm wondering why the timePeriodMillis option has been removed for the
> > throttle EIP.
> >
> > I have an endpoint that can only receive about 5 requests per minute, else
> > the request will fail. I accounted for that by using a timePeriodMillis
> > setting of 6 ms and a throttle value of 4.
> > Now with the updated Throttle EIP I can't do that anymore.
> >
> > The upgrade guide suggests that the default time period is 1000 ms now,
> > but obviously I can't work with that:
> > https://camel.apache.org/manual/camel-4x-upgrade-guide-4_3.html#_throttle_eip
> >
> > Any suggestions?
> >
> > Best regards
> >
> 
> 
> -- 
> Otavio R. Piske
> http://orpiske.net
>

How to make Camel cloud cron "friendly"

2024-02-02 Thread Pasquale Congiusti

Hi folks,
I'm working lately on some experiment to run a generic Camel application on
a Kubernetes CronJob. The behavior expected by the cluster is that, once
the job workload is over, the application would exit with either a success
or error code. As we're running a Camel application, although the route may
have finished, the entire application will continue to run until a forceful
shutdown. I am not sure it exists any other way, so I found my way to
workaround this behavior by following the approach in [1], which would ends
up in something like the following code:

public class TestCron extends RouteBuilder {
@Override
public void configure() throws Exception {
from("timer:cron?delay=0=1=1")
// Simulate heavylift work
.delay(1)
.to("log:info")
.log("DONE!")
.process(new Processor() {
Thread stop;
@Override
public void process(final Exchange exchange) throws Exception {
if (stop == null) {
stop = new Thread() {
@Override
public void run() {
try {
exchange.getContext().stop();
} catch (Exception e) {
// ignore
}
}
};
}
// start the thread that stops the context
stop.start();
}
});
}
}

However, this workaround feels a bit too hacky as it involves playing with
Camel Context directly. It is also impossible to reproduce easily in non
Java DSL, like in YAML. I am wondering if we can think on having a higher
level EIP such we have with "stop", something like "shutdown" which
behavior may be similar of what described above, taking care to gracefully
shutdown the application when it is invoked. This one may do some finer
grained controls to verify that the exchanges has really completed or there
are no others routes running or any other low level check that would
perform a controlled shutdown. How does it sound? or which would be any
alternative to make Camel more cloud cron "friendly"?

Regards,
Pasquale.

[1]
https://camel.apache.org/manual/faq/how-can-i-stop-a-route-from-a-route.html#HowcanIstoparoutefromaroute-Usingathreadtostoparoutefromaroute

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

Re: How to make Camel cloud cron "friendly"

Re: How to make Camel cloud cron "friendly"

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

Re: Why has timePeriodMillis for the Throttle EIP been removed and how can I account for this

How to make Camel cloud cron "friendly"

7 matches

Site Navigation

Mail list logo

Footer information