Greetings. Apologies for coming in a bit late on this conversation. Tristan pointed me to it a couple of days ago and unfortunately I'm just now getting time to reply. I can try to quickly give an overview of apiman's (JBoss API Management Gateway) requirements. What we're trying to do is implement support for Limiting policies: * Rate Limiting/Throttling (e.g. limit of 100 requests per second) * Quotas (e.g. limit of 100,000,000 requests per month) * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) We will need to support multiple backing implementations of the Rate Limiter, and we're trying to get Infinispan to be one of those implementations. In no particular order, we would need the following characteristics: - Can be "squishy" for quotas and transfer quotas: If you get 100,001,017 requests that's OK - Strict would be cool as an option: Hard-fail when the counter reaches the limit - no chance it will go over. - Lots of individual counters: users may publish 100s of APIs to the Gateway, and each API may be consumed by 100s or 1000s of users/client. Depending on configuration of the policy, *each* user/client has a separate limit. - Counters need to be created dynamically: users can add APIs via the Management UI, configure them to add policies (e.g. a Quota policy) and then publish them to a running Gateway, at which point end users can invoke the API through the Gateway, which will use a counter to enforce the Quota. - Counter values reset at the end of a time boundary: for example, at the end of the month the counter value for the example quota above would reset to 0. - Don't care (right now) what the counter value is: at the moment we simply need to know if some counter max value has been reached. In the future we would like to know when a max value is being "approached" (e.g. to notify a user) - Should be persistent: it would not be ideal for e.g. per- month quota values to be lost on server restart. That's all the high level requirements I can think of off the top of my head, and after reading all of the current messages in this thread. :) -Eric _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Yes, precisely. The API Gateway itself is clustered. It services a large volume of inbound traffic which it reverse-proxies to appropriate back-end APIs after applying policies such as security, rate limiting, caching, etc. -Eric On 3/18/2016 2:32 AM, Bela Ban wrote: > Stupid question: whay do you need a distributed counter for this? Is the > service you're monitoring replicated in a cluster? > > On 17/03/16 18:06, Eric Wittmann wrote: >> Greetings. Apologies for coming in a bit late on this conversation. >> Tristan pointed me to it a couple of days ago and unfortunately I'm just >> now getting time to reply. >> >> I can try to quickly give an overview of apiman's (JBoss API Management >> Gateway) requirements. >> >> What we're trying to do is implement support for Limiting policies: >> >> * Rate Limiting/Throttling (e.g. limit of 100 requests per second) >> * Quotas (e.g. limit of 100,000,000 requests per month) >> * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) >> >> We will need to support multiple backing implementations of the Rate >> Limiter, and we're trying to get Infinispan to be one of those >> implementations. >> >> In no particular order, we would need the following characteristics: >> >> - Can be "squishy" for quotas and transfer quotas: If you >> get 100,001,017 requests that's OK >> - Strict would be cool as an option: Hard-fail when the >> counter reaches the limit - no chance it will go over. >> - Lots of individual counters: users may publish 100s of >> APIs to the Gateway, and each API may be consumed by >> 100s or 1000s of users/client. Depending on configuration >> of the policy, *each* user/client has a separate limit. >> - Counters need to be created dynamically: users can >> add APIs via the Management UI, configure them to add >> policies (e.g. a Quota policy) and then publish them to >> a running Gateway, at which point end users can invoke >> the API through the Gateway, which will use a counter >> to enforce the Quota. >> - Counter values reset at the end of a time boundary: for >> example, at the end of the month the counter value for >> the example quota above would reset to 0. >> - Don't care (right now) what the counter value is: at the >> moment we simply need to know if some counter max value >> has been reached. In the future we would like to know >> when a max value is being "approached" (e.g. to notify a >> user) >> - Should be persistent: it would not be ideal for e.g. per- >> month quota values to be lost on server restart. >> >> That's all the high level requirements I can think of off the top of my >> head, and after reading all of the current messages in this thread. :) >> >> -Eric >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

Agreed. :) On 3/18/2016 9:31 AM, Bela Ban wrote: > So actually you don't care if you have multiple counters in case of a > network split, but you do care that the numbers of different counters > get reconciled when a network partition heals. > > Example > - C1: 1000 > - Network split: C1: 1000, C2: 1000 > - Different clients update counters on both sides of the partition: C1: > 1500 C2: 1600 > - Network split disappears, reconciling C1 to 2100: 1000 +500 +600. This > means the 500 added to C1 should have been added to C2 as well, and the > 600 to C2 should have been added to C1 > > If such a behavior would be acceptable, then we could do without CP and > live with AP > > On 18/03/16 14:19, Eric Wittmann wrote: >> Yes, precisely. The API Gateway itself is clustered. It services a >> large volume of inbound traffic which it reverse-proxies to appropriate >> back-end APIs after applying policies such as security, rate limiting, >> caching, etc. >> >> -Eric >> >> On 3/18/2016 2:32 AM, Bela Ban wrote: >>> Stupid question: whay do you need a distributed counter for this? Is the >>> service you're monitoring replicated in a cluster? >>> >>> On 17/03/16 18:06, Eric Wittmann wrote: >>>> Greetings. Apologies for coming in a bit late on this conversation. >>>> Tristan pointed me to it a couple of days ago and unfortunately I'm just >>>> now getting time to reply. >>>> >>>> I can try to quickly give an overview of apiman's (JBoss API Management >>>> Gateway) requirements. >>>> >>>> What we're trying to do is implement support for Limiting policies: >>>> >>>> * Rate Limiting/Throttling (e.g. limit of 100 requests per second) >>>> * Quotas (e.g. limit of 100,000,000 requests per month) >>>> * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) >>>> >>>> We will need to support multiple backing implementations of the Rate >>>> Limiter, and we're trying to get Infinispan to be one of those >>>> implementations. >>>> >>>> In no particular order, we would need the following characteristics: >>>> >>>> - Can be "squishy" for quotas and transfer quotas: If you >>>> get 100,001,017 requests that's OK >>>> - Strict would be cool as an option: Hard-fail when the >>>> counter reaches the limit - no chance it will go over. >>>> - Lots of individual counters: users may publish 100s of >>>> APIs to the Gateway, and each API may be consumed by >>>> 100s or 1000s of users/client. Depending on configuration >>>> of the policy, *each* user/client has a separate limit. >>>> - Counters need to be created dynamically: users can >>>> add APIs via the Management UI, configure them to add >>>> policies (e.g. a Quota policy) and then publish them to >>>> a running Gateway, at which point end users can invoke >>>> the API through the Gateway, which will use a counter >>>> to enforce the Quota. >>>> - Counter values reset at the end of a time boundary: for >>>> example, at the end of the month the counter value for >>>> the example quota above would reset to 0. >>>> - Don't care (right now) what the counter value is: at the >>>> moment we simply need to know if some counter max value >>>> has been reached. In the future we would like to know >>>> when a max value is being "approached" (e.g. to notify a >>>> user) >>>> - Should be persistent: it would not be ideal for e.g. per- >>>> month quota values to be lost on server restart. >>>> >>>> That's all the high level requirements I can think of off the top of my >>>> head, and after reading all of the current messages in this thread. :) >>>> >>>> -Eric >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 21/03/16 11:12, Pedro Ruivo wrote: > Hi all, > > @Eric, thanks for the requirements. > > @Bela, does JGroups counter supports that semantics (AP)? No. You'd have to catch the MergeView and do this manually.

> Infinispan does not have eventually consistency (yet) neither an update log. So, it > can't reconcile the counter and you will lose one of the partition updates. Same for the JGroups counter service. The jgroups-raft CounterService provides strong consistency, but at the expense of availability. > On 03/18/2016 02:19 PM, Eric Wittmann wrote: >> Agreed. :) >> >> On 3/18/2016 9:31 AM, Bela Ban wrote: >>> So actually you don't care if you have multiple counters in case of a >>> network split, but you do care that the numbers of different counters >>> get reconciled when a network partition heals. >>> >>> Example >>> - C1: 1000 >>> - Network split: C1: 1000, C2: 1000 >>> - Different clients update counters on both sides of the partition: C1: >>> 1500 C2: 1600 >>> - Network split disappears, reconciling C1 to 2100: 1000 +500 +600. This >>> means the 500 added to C1 should have been added to C2 as well, and the >>> 600 to C2 should have been added to C1 >>> >>> If such a behavior would be acceptable, then we could do without CP and >>> live with AP >>> >>> On 18/03/16 14:19, Eric Wittmann wrote: >>>> Yes, precisely. The API Gateway itself is clustered. It services a >>>> large volume of inbound traffic which it reverse-proxies to appropriate >>>> back-end APIs after applying policies such as security, rate limiting, >>>> caching, etc. >>>> >>>> -Eric >>>> >>>> On 3/18/2016 2:32 AM, Bela Ban wrote: >>>>> Stupid question: whay do you need a distributed counter for this? Is the >>>>> service you're monitoring replicated in a cluster? >>>>> >>>>> On 17/03/16 18:06, Eric Wittmann wrote: >>>>>> Greetings. Apologies for coming in a bit late on this conversation. >>>>>> Tristan pointed me to it a couple of days ago and unfortunately I'm just >>>>>> now getting time to reply. >>>>>> >>>>>> I can try to quickly give an overview of apiman's (JBoss API Management >>>>>> Gateway) requirements. >>>>>> >>>>>> What we're trying to do is implement support for Limiting policies: >>>>>> >>>>>> * Rate Limiting/Throttling (e.g. limit of 100 requests per second) >>>>>> * Quotas (e.g. limit of 100,000,000 requests per month) >>>>>> * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) >>>>>> >>>>>> We will need to support multiple backing implementations of the Rate >>>>>> Limiter, and we're trying to get Infinispan to be one of those >>>>>> implementations. >>>>>> >>>>>> In no particular order, we would need the following characteristics: >>>>>> >>>>>> - Can be "squishy" for quotas and transfer quotas: If you >>>>>> get 100,001,017 requests that's OK >>>>>> - Strict would be cool as an option: Hard-fail when the >>>>>> counter reaches the limit - no chance it will go over. >>>>>> - Lots of individual counters: users may publish 100s of >>>>>> APIs to the Gateway, and each API may be consumed by >>>>>> 100s or 1000s of users/client. Depending on configuration >>>>>> of the policy, *each* user/client has a separate limit. >>>>>> - Counters need to be created dynamically: users can >>>>>> add APIs via the Management UI, configure them to add >>>>>> policies (e.g. a Quota policy) and then publish them to >>>>>> a running Gateway, at which point end users can invoke >>>>>> the API through the Gateway, which will use a counter >>>>>> to enforce the Quota. >>>>>> - Counter values reset at the end of a time boundary: for >>>>>> example, at the end of the month the counter value for >>>>>> the example quota above would reset to 0. >>>>>> - Don't care (right now) what the counter value is: at the >>>>>> moment we simply need to know if some counter max value >>>>>> has been reached. In the future we would like to know >>>>>> when a max value is being "approached" (e.g. to notify a >>>>>> user) >>>>>> - Should be persistent: it would not be ideal for e.g. per- >>>>>> month quota values to be lost on server restart. >>>>>> >>>>>> That's all the high level requirements I can think of off the top of my >>>>>> head, and after reading all of the current messages in this thread. :) >>>>>> >>>>>> -Eric >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> infinispan-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>> >>>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 22/03/16 18:04, Dan Berindei wrote: > On Mon, Mar 21, 2016 at 1:43 PM, Bela Ban <bban(a)redhat.com&gt; wrote: >> >> >> On 21/03/16 11:12, Pedro Ruivo wrote: >>> Hi all, >>> >>> @Eric, thanks for the requirements. >>> >>> @Bela, does JGroups counter supports that semantics (AP)? >> >> No. You'd have to catch the MergeView and do this manually. > > I should also mention that you don't get a "cluster split" event. With > when a cluster ABC splits into A and BC and merges back, you could get > quite a view sequence like this: > > A, B, C: A|3 [A, B, C] > A: A|4 [A, B] > A: A|5 [A] (could be missing) How's that possible? Are you assuming that A still gets heartbeats from B? Otherwise A will definitely get a singleton view A|5=[A], unless the cluster heals in the meantime (before B is suspected and excluded).

Note that A|4 on A may or may not be received; if FD_ALL is used then chances are view [A] will be received directly after [ABC] on A.

> B, C: B|4 [B, C] > A, B, C: B|6 [B, C, A] (merge view) Note that you could keep the order if you installed a custom view/merge-view creation policy, but by default members are sorted according to the UUIDs. > So it's not that easy to keep track of counter additions "since the split". Agreed. >>> Infinispan does not have eventually consistency (yet) neither an update log. So, it >>> can't reconcile the counter and you will lose one of the partition updates. >> >> Same for the JGroups counter service. The jgroups-raft CounterService >> provides strong consistency, but at the expense of availability. >> >>> On 03/18/2016 02:19 PM, Eric Wittmann wrote: >>>> Agreed. :) >>>> >>>> On 3/18/2016 9:31 AM, Bela Ban wrote: >>>>> So actually you don't care if you have multiple counters in case of a >>>>> network split, but you do care that the numbers of different counters >>>>> get reconciled when a network partition heals. >>>>> >>>>> Example >>>>> - C1: 1000 >>>>> - Network split: C1: 1000, C2: 1000 >>>>> - Different clients update counters on both sides of the partition: C1: >>>>> 1500 C2: 1600 >>>>> - Network split disappears, reconciling C1 to 2100: 1000 +500 +600. This >>>>> means the 500 added to C1 should have been added to C2 as well, and the >>>>> 600 to C2 should have been added to C1 >>>>> >>>>> If such a behavior would be acceptable, then we could do without CP and >>>>> live with AP >>>>> >>>>> On 18/03/16 14:19, Eric Wittmann wrote: >>>>>> Yes, precisely. The API Gateway itself is clustered. It services a >>>>>> large volume of inbound traffic which it reverse-proxies to appropriate >>>>>> back-end APIs after applying policies such as security, rate limiting, >>>>>> caching, etc. >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 3/18/2016 2:32 AM, Bela Ban wrote: >>>>>>> Stupid question: whay do you need a distributed counter for this? Is the >>>>>>> service you're monitoring replicated in a cluster? >>>>>>> >>>>>>> On 17/03/16 18:06, Eric Wittmann wrote: >>>>>>>> Greetings. Apologies for coming in a bit late on this conversation. >>>>>>>> Tristan pointed me to it a couple of days ago and unfortunately I'm just >>>>>>>> now getting time to reply. >>>>>>>> >>>>>>>> I can try to quickly give an overview of apiman's (JBoss API Management >>>>>>>> Gateway) requirements. >>>>>>>> >>>>>>>> What we're trying to do is implement support for Limiting policies: >>>>>>>> >>>>>>>> * Rate Limiting/Throttling (e.g. limit of 100 requests per second) >>>>>>>> * Quotas (e.g. limit of 100,000,000 requests per month) >>>>>>>> * Transfer Quotas (e.g. limit of 2.5GB of data downloaded per day) >>>>>>>> >>>>>>>> We will need to support multiple backing implementations of the Rate >>>>>>>> Limiter, and we're trying to get Infinispan to be one of those >>>>>>>> implementations. >>>>>>>> >>>>>>>> In no particular order, we would need the following characteristics: >>>>>>>> >>>>>>>> - Can be "squishy" for quotas and transfer quotas: If you >>>>>>>> get 100,001,017 requests that's OK >>>>>>>> - Strict would be cool as an option: Hard-fail when the >>>>>>>> counter reaches the limit - no chance it will go over. >>>>>>>> - Lots of individual counters: users may publish 100s of >>>>>>>> APIs to the Gateway, and each API may be consumed by >>>>>>>> 100s or 1000s of users/client. Depending on configuration >>>>>>>> of the policy, *each* user/client has a separate limit. >>>>>>>> - Counters need to be created dynamically: users can >>>>>>>> add APIs via the Management UI, configure them to add >>>>>>>> policies (e.g. a Quota policy) and then publish them to >>>>>>>> a running Gateway, at which point end users can invoke >>>>>>>> the API through the Gateway, which will use a counter >>>>>>>> to enforce the Quota. >>>>>>>> - Counter values reset at the end of a time boundary: for >>>>>>>> example, at the end of the month the counter value for >>>>>>>> the example quota above would reset to 0. >>>>>>>> - Don't care (right now) what the counter value is: at the >>>>>>>> moment we simply need to know if some counter max value >>>>>>>> has been reached. In the future we would like to know >>>>>>>> when a max value is being "approached" (e.g. to notify a >>>>>>>> user) >>>>>>>> - Should be persistent: it would not be ideal for e.g. per- >>>>>>>> month quota values to be lost on server restart. >>>>>>>> >>>>>>>> That's all the high level requirements I can think of off the top of my >>>>>>>> head, and after reading all of the current messages in this thread. :) >>>>>>>> >>>>>>>> -Eric >>>>>>>> _______________________________________________ >>>>>>>> infinispan-dev mailing list >>>>>>>> infinispan-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> infinispan-dev mailing list >>>>>> infinispan-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>>>> >>>>> >>>> _______________________________________________ >>>> infinispan-dev mailing list >>>> infinispan-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>>> >>> _______________________________________________ >>> infinispan-dev mailing list >>> infinispan-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >>> >> >> -- >> Bela Ban, JGroups lead (http://www.jgroups.org) >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > -- Bela Ban, JGroups lead (http://www.jgroups.org) _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev