<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 10/5/16 2:57 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A4D130@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">
That's the big stuff, probably also some ratios on cache hits/misses. Might also be good to look at instrumenting the HttpClient as part of this.</pre>
</blockquote>
<br>
I hadn't thought about HttpClient. That sort of implies that some
of this (dependencies, disabled stuff, etc) needs to live as far
down as java-support, so that we could return wrapped (or otherwise
modified) HC instances from our HttpClientBuilder. Would we want
just basic request/response timing? That seems easy via wrapping
it. I guess could also do # of requests to individual domains, or
for particular URIs, etc, if you can create the gauge name
dynamically.<br>
<br>
Probably would want a flag on the builder as to whether to return an
instrumented client instance.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A4D130@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">It isn't practical to wrap everything, there are too many interdependent classes (Histograms, Reservoirs). The work to wrap it would be more than the work to import all the code in the future and just take it over. What I like about Metrics is it's so brain-dead. It's basically the bare minimum you'd implement to do these things.
All I dead was implement stubs for disabled metrics and a lot of work on managing them.
</pre>
</blockquote>
<br>
That's fine. So at this point I'm mostly just wondering about the
dependency mgmt and where any necessary custom classes would live.
Sounds like maybe it's lower than java-opensaml.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A4D130@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"><br>
<pre wrap="">I suppose it's similar, yes. But CriteriaSet only takes us so far, we'll run into something that doesn't have that kind of input model. </pre>
</blockquote>
<br>
Yeah, it's not a general solution.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A4D130@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<pre wrap="">Either way, the basic issue is the API. We either have to create the dependency, or report the data out generically so I can wrap the resolver(s) like I just did with the services.</pre>
</blockquote>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112A4D130@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
</blockquote>
<br>
Well, unless we have other ideas, I suppose we just have to bite the
bullet and introduce the Metrics dependency. It doesn't overwhelm
me with joy, but I guess ultimately it's like picking any other
dependency. It's not unlike picking a logging library in fact
(albeit without the facade abstraction that slf4j provides).<br>
</body>
</html>