You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Floriane Allaire (Jira)" <ji...@apache.org> on 2021/06/15 07:45:00 UTC

[jira] [Updated] (NIFI-8703) Rate Limiter Processor

     [ https://issues.apache.org/jira/browse/NIFI-8703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Floriane Allaire updated NIFI-8703:
-----------------------------------
    Description: 
h2. Rate Limiter Record Processor

The objective of this issue is to bring to the community a new type of processor to enable the limitation of incoming traffic. Using a CacheBuilder from Guava and buckets from Bucket4j, this processor can read a bucket key from the record or the default value given by the attribute, and check if the rate limit is respected. You have several parameters to configure the rate limiter like, refill tokens, refill period, bandwidth capacity, max size bucket, and expire duration. All of witch have specific descriptions reusing the apache documentation of the Bucket4j library. 

However, I would like to know if an internal cache controller using bucket4j should be integrated into the processor ( initialized using onScheduled and onUnScheduled ) or have its own controller service? 

I'm also not sure if using onScheduled is better, or if I should use the onStart function? 

I would be grateful for all of your advice. This would be very helpful for me to build this new processor, which I would like to share with the community. 

 

  was:
h2. Rate Limiter Record Processor

The objective of this issue is to bring to the community a new type of processor to enable the limitation of incoming traffic. Using a CacheBuilder from Bucket4j, this processor can read a bucket key from the record or the default value given by the attribute, and check if the rate limit is respected. You have several parameters to configure the rate limiter like, refill tokens, refill period, bandwidth capacity, max size bucket, and expire duration. All of witch have specific descriptions reusing the apache documentation of the Bucket4j library. 

However, I would like to know if an internal cache controller using bucket4j should be integrated into the processor ( initialized using onScheduled and onUnScheduled ) or have its own controller service? 

I'm also not sure if using onScheduled is better, or if I should use the onStart function? 

I would be grateful for all of your advice. This would be very helpful for me to build this new processor, which I would like to share with the community. 

 


> Rate Limiter Processor
> ----------------------
>
>                 Key: NIFI-8703
>                 URL: https://issues.apache.org/jira/browse/NIFI-8703
>             Project: Apache NiFi
>          Issue Type: New Feature
>    Affects Versions: 1.13.2
>         Environment: CentOS Linux 7 (Core)
>            Reporter: Floriane Allaire
>            Priority: Minor
>              Labels: features, newbie
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> h2. Rate Limiter Record Processor
> The objective of this issue is to bring to the community a new type of processor to enable the limitation of incoming traffic. Using a CacheBuilder from Guava and buckets from Bucket4j, this processor can read a bucket key from the record or the default value given by the attribute, and check if the rate limit is respected. You have several parameters to configure the rate limiter like, refill tokens, refill period, bandwidth capacity, max size bucket, and expire duration. All of witch have specific descriptions reusing the apache documentation of the Bucket4j library. 
> However, I would like to know if an internal cache controller using bucket4j should be integrated into the processor ( initialized using onScheduled and onUnScheduled ) or have its own controller service? 
> I'm also not sure if using onScheduled is better, or if I should use the onStart function? 
> I would be grateful for all of your advice. This would be very helpful for me to build this new processor, which I would like to share with the community. 
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)