Freeze?

[Brent Putman]

On 10/27/16 5:01 PM, Cantor, Scott wrote:
>> Actually, I just commented in the issue, but I think maybe just timing things is
>> better, and gives you a Meter as a part of that.  I think.
> I think the idea is Timers tell you how long something takes and Meters how often something happens. Obviously each time you take a timer measure, you're recording an event so I guess it's a superset.

Ok, yes, that's how I understand.  Looking at the Timer code, it's
literally a Meter + Histogram + Clock.  So it really is a composition.

>
> Yeah, I don't know that it works for my situation, which is a conclusion I came to this AM when I studied this, but my point was it might work for your case of exposing the different values by entityID since that's more self-contained data.

Ok, yeah, for the entityID case that certainly makes sense, since the
individual resolver knows about everything under its management.


>> And then it gets the various metrics objects based on being able to construct
>> the Metrics name from the component ID?  Or something like that?
> My parallel point was that I didn't make the component ID part of the metric name. Instead I made the metric a Gauge over a Map keyed by the component ID.
>
>> Or maybe somehow there's a shared Map that each component adds data
>> to, but I'm not clear on that yet...
> I think there are a lot of patterns, just will take some playing around and if we can try a few and reserve the right to change them later, we're ok.


I'll hold off on any of that then.  I think this would required
coordination with components at a higher level, which I think is
essentially what you are already doing in the reloadable service layer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161027/6dc8d355/attachment-0001.html>