<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 9/16/16 4:36 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:1F556378-C48C-4539-A500-9F4E57267CB6@osu.edu"
type="cite"><br>
<pre wrap="">
I think the whole metrics-core code base is fairly small and mostly taken up by the built-in Reporters and the rest is just a bunch of map maintenance code.</pre>
</blockquote>
<br>
Presumably all the collected data is just maintained in memory. Do
they discuss how/when data is reaped? Maybe it's obvious, I haven't
read up. But I'm just thinking in general about memory usage if the
IdP is running for months at a time.<br>
<br>
<blockquote cite="mid:1F556378-C48C-4539-A500-9F4E57267CB6@osu.edu"
type="cite"><br>
<pre wrap="">I hadn't thought of that. The two could probably be combined, meaning a simple implementation of the code to return the objects that might be no-op'd might be based on use of logging categories, just to save the work of reimplementing something exactly like it.
</pre>
</blockquote>
<br>
Yes, marrying the two would work well, I think.<br>
<br>
<br>
<blockquote cite="mid:1F556378-C48C-4539-A500-9F4E57267CB6@osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">That granularity and hierarchical config does seem nice to have, if it
can be made to work.
</pre>
</blockquote>
<pre wrap="">
The naming's entirely up to us so there's no reason we can't do it. I don't think that the metrics necessarily correspond to class names like the loggers do, particularly since so many are impl classes, but the same general package names should apply.</pre>
</blockquote>
<br>
Just so as to not mix and conflate the actual logging config and the
metrics, might want to optionally auto-prepend a separate prefix or
something for the metrics categories. So logging and metrics
categories are really separate.<br>
<br>
<br>
<blockquote cite="mid:1F556378-C48C-4539-A500-9F4E57267CB6@osu.edu"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Hmm, yeah, good point. I thought they mentioned stuff about being
thread-safe everywhere, but maybe it doesn't work if you are literally
trying to register an existing name.At least the ones like
counter(...) though use a getOrAdd approach, so I think those might
actually work within the prototypes. Maybe for the register(...), e.g.
of a Guage, they have a way to get an existing one rather than create a
new one. They do have Maps of all these things on the registry.
</pre>
</blockquote>
<pre wrap="">
Are they documented that way, or did you just look at the counter() code? I didn't see any sign that's a contract they're making.</pre>
</blockquote>
<br>
No, I don't see any docs. I just noticed the code. So you're right
in that it might not be guaranteed.<br>
<br>
<br>
<blockquote cite="mid:1F556378-C48C-4539-A500-9F4E57267CB6@osu.edu"
type="cite">
<pre wrap="">
If something in particular is expensive to even gather and push into a metric, we could define an interface (DisabledMetric) to implement on the no-op cases so that we'd have the ability to guard that in the classes if we needed it. That's what I envisioned with the logging idea, but that could be abstracted away.</pre>
</blockquote>
<br>
Yeah, the conceptual equivalent and use case of Logger
isDebugEnabled() and friends.<br>
<br>
<br>
</body>
</html>