Freeze?

[Brent Putman]

On 10/27/16 4:10 PM, Cantor, Scott wrote:
>> Mainly what I was going to do was change use of Counter to Meter.  It seems
>> more appropriate.  You can still get the total count from the Meter, but also
>> get 1, 5, 15 minute averages.  The Counter seems more appropriate for
>> increment/decrement cases.
> Wasn't sure (and I haven't fully grokked Meter yet) but I wondered about that.

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. 

In any case, I don't know why I initially omitted, but I do think it
would be desirable to just time the whole resolve() method as well as
the origin fetch.

>> In this approach, is the Map<String,whatever> returned by the gauge
>> dynamic?
> It's dynamic because I'm building it in the Gauge's getValue() method, yes. Could be cached, but it's not expensive to build so I didn't make it cached.

Ok, so you inject the resolver instance(s) into the gauge, and then you
can pull data from its properties dynamically.


>
> The Gauge isn't currently backed by Metrics objects because the public API for that data is sitting on RefreshableMetadataResolver as explicit DateTime-returning methods (and we can't go changing the interface), not as Gauges.
>
> So the Gauge builds a Map out of raw data.

Oh, right, b/c the data is the update time, etc from the resolvesr.  Ok,
that's different than my case here.

I may take a stab at a gauge backed by other metrics objects.  They have
examples of that.

Not sure yet how the Map<String,T> idea works.  If the String key is the
component ID, then doesn't that Gauge have to be created and managed by
something that knows about all the (in the this case) metadata
resolvers?  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?

Or maybe somehow there's a shared Map that each component adds data to,
but I'm not clear on that yet...


>
>  I may suggest we just explicitly document that the actual metric names and groupings are not considered stable API for the time being, just so people don't make assumptions we're locked into.

That seems prudent to me.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20161027/9550033b/attachment.html>