wildcarded resource counters in Gproc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

wildcarded resource counters in Gproc

Ulf Wiger-2
There's a new PR on Gproc, adding support for limited wildcard matching in resource counters.


I don't know how many people use resource counters ('rc'), but thought I'd ask.

The operation of registering (or unregistering) a resource now makes one extra update_counter() protected by a try ... catch. My assumption is that this extra overhead will be insignificant to just about all use cases, but ... does anyone out there want to disagree?

Briefly, when registering a resource ('r') object, gproc would try to perform an update_counter on the corresponding 'rc' object - an operation that might fail if the 'rc' object doesn't exist. Now, if the name of the resource is a tuple, it also tries to update an 'rc' object with the last element of the name tuple replaced with '\\_'. This make it possible to count resources whose names differ in only the last tuple element. For non-tuple resource names, it works just like before.

BR,
Ulf W

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Garrett Smith-5
This doesn't feel right to me - it strikes me as edge case support
that's impacting what's otherwise a very simple feature.

If this is generally useful, would it make sense to implement it as a
new function call, which made the additional update explicit?

On Thu, Dec 1, 2016 at 11:11 AM, Ulf Wiger <[hidden email]> wrote:

> There's a new PR on Gproc, adding support for limited wildcard matching in
> resource counters.
>
> https://github.com/uwiger/gproc/pull/128
>
> I don't know how many people use resource counters ('rc'), but thought I'd
> ask.
>
> The operation of registering (or unregistering) a resource now makes one
> extra update_counter() protected by a try ... catch. My assumption is that
> this extra overhead will be insignificant to just about all use cases, but
> ... does anyone out there want to disagree?
>
> Briefly, when registering a resource ('r') object, gproc would try to
> perform an update_counter on the corresponding 'rc' object - an operation
> that might fail if the 'rc' object doesn't exist. Now, if the name of the
> resource is a tuple, it also tries to update an 'rc' object with the last
> element of the name tuple replaced with '\\_'. This make it possible to
> count resources whose names differ in only the last tuple element. For
> non-tuple resource names, it works just like before.
>
> BR,
> Ulf W
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Garrett Smith-5
And another tack - is there a path here to a generalized interface for
alternative schemes? E.g. passing along a function to do some work on
the table? Maybe not for the faint of heart, but this would reduce the
temptation to modify the interface for these case.

On Thu, Dec 1, 2016 at 12:11 PM, Garrett Smith <[hidden email]> wrote:

> This doesn't feel right to me - it strikes me as edge case support
> that's impacting what's otherwise a very simple feature.
>
> If this is generally useful, would it make sense to implement it as a
> new function call, which made the additional update explicit?
>
> On Thu, Dec 1, 2016 at 11:11 AM, Ulf Wiger <[hidden email]> wrote:
>> There's a new PR on Gproc, adding support for limited wildcard matching in
>> resource counters.
>>
>> https://github.com/uwiger/gproc/pull/128
>>
>> I don't know how many people use resource counters ('rc'), but thought I'd
>> ask.
>>
>> The operation of registering (or unregistering) a resource now makes one
>> extra update_counter() protected by a try ... catch. My assumption is that
>> this extra overhead will be insignificant to just about all use cases, but
>> ... does anyone out there want to disagree?
>>
>> Briefly, when registering a resource ('r') object, gproc would try to
>> perform an update_counter on the corresponding 'rc' object - an operation
>> that might fail if the 'rc' object doesn't exist. Now, if the name of the
>> resource is a tuple, it also tries to update an 'rc' object with the last
>> element of the name tuple replaced with '\\_'. This make it possible to
>> count resources whose names differ in only the last tuple element. For
>> non-tuple resource names, it works just like before.
>>
>> BR,
>> Ulf W
>>
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Ulf Wiger-2
In reply to this post by Garrett Smith-5
Hi Garrett,

Thanks for playing. ;-)

In the case I have in mind, a given process may need to register multiple instances of a resource, where the key is basically {ServiceName, Route}. The resource count should keep track of instances of ServiceName, and especially trigger when the count reaches 0 (service no longer available).

While one could add an extra function that creates a resource, also updating a wildcarded resource count, this opens up for possible bugs where the wrong function is used to create a resource, throwing the count out of sync.

The proposed change was the most lightweight way I could think of to extend the 'rc' type, essentially adding one more layer of abstraction to it. But if there is another way, efficient and elegant, I'm wide open to suggestions.

BR,
Ulf W

2016-12-01 19:11 GMT+01:00 Garrett Smith <[hidden email]>:
This doesn't feel right to me - it strikes me as edge case support
that's impacting what's otherwise a very simple feature.

If this is generally useful, would it make sense to implement it as a
new function call, which made the additional update explicit?

On Thu, Dec 1, 2016 at 11:11 AM, Ulf Wiger <[hidden email]> wrote:
> There's a new PR on Gproc, adding support for limited wildcard matching in
> resource counters.
>
> https://github.com/uwiger/gproc/pull/128
>
> I don't know how many people use resource counters ('rc'), but thought I'd
> ask.
>
> The operation of registering (or unregistering) a resource now makes one
> extra update_counter() protected by a try ... catch. My assumption is that
> this extra overhead will be insignificant to just about all use cases, but
> ... does anyone out there want to disagree?
>
> Briefly, when registering a resource ('r') object, gproc would try to
> perform an update_counter on the corresponding 'rc' object - an operation
> that might fail if the 'rc' object doesn't exist. Now, if the name of the
> resource is a tuple, it also tries to update an 'rc' object with the last
> element of the name tuple replaced with '\\_'. This make it possible to
> count resources whose names differ in only the last tuple element. For
> non-tuple resource names, it works just like before.
>
> BR,
> Ulf W
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Ulf Wiger-2
In reply to this post by Garrett Smith-5


2016-12-01 19:18 GMT+01:00 Garrett Smith <[hidden email]>:
And another tack - is there a path here to a generalized interface for
alternative schemes? E.g. passing along a function to do some work on
the table? Maybe not for the faint of heart, but this would reduce the
temptation to modify the interface for these case.

One complication that comes to mind is the need for symmetry - at least in the case of aggregated counters and resource counters: they need to increment on one end and correspondingly decrement on the other.

There is of course also the question of how much functionality can be crammed into gproc before people simply give up. :)

But again, open to suggestions and PRs.

BR,
Ulf W 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Garrett Smith-5
I need to set aside some time - and compared to some of the recent
events in global politics, this is not a super big deal.

My line of inquiry would be a second type of counter where the key
contained parts - and incrementing this type of counter added
additional wild card entries up the path - so any level of wild
carding is possible.

I can't really make any informed statement without playing around.
This just strikes me as a new type of counter.

On Thu, Dec 1, 2016 at 3:19 PM, Ulf Wiger <[hidden email]> wrote:

>
>
> 2016-12-01 19:18 GMT+01:00 Garrett Smith <[hidden email]>:
>>
>> And another tack - is there a path here to a generalized interface for
>> alternative schemes? E.g. passing along a function to do some work on
>> the table? Maybe not for the faint of heart, but this would reduce the
>> temptation to modify the interface for these case.
>
>
> One complication that comes to mind is the need for symmetry - at least in
> the case of aggregated counters and resource counters: they need to
> increment on one end and correspondingly decrement on the other.
>
> There is of course also the question of how much functionality can be
> crammed into gproc before people simply give up. :)
>
> But again, open to suggestions and PRs.
>
> BR,
> Ulf W
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Ulf Wiger-2


2016-12-01 22:45 GMT+01:00 Garrett Smith <[hidden email]>:
I need to set aside some time - and compared to some of the recent
events in global politics, this is not a super big deal.

You wound me. ;-)

I am working on a more general solution. It's about as painful as I suspected, but you were of course right in voicing your objections. That was the reason why I posted the question, after all.

I'll return shortly with a new PR.

BR,
Ulf 


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Anthony Ramine-4
In reply to this post by Ulf Wiger-2
Out of curiosity, shouldn't you use ets:update_counter/4?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: wildcarded resource counters in Gproc

Ulf Wiger-2
That wasn't what the catch was for. Rather, it optimistically tries to update an aggregated counter that may or may not be there. It should NOT be created if it doesn't exist.

The change that Garrett didn't like was that it optimistically tried to update TWO different aggregated counters instead of just one.

BR,
Ulf W

2017-01-21 15:48 GMT+00:00 Anthony Ramine <[hidden email]>:
Out of curiosity, shouldn't you use ets:update_counter/4?


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions