markrmiller commented on pull request #53: URL: https://github.com/apache/solr/pull/53#issuecomment-932677247
Nice, this can be a very expensive call and there is no real limit on how often metrics may be generated - in a jmx case it was the case and may still be that for every metric in a group added in a loop, every metrics in that group was asked to generate. However, I do wonder about the one off implementation and refresh control. Almost every metric that exists with more than counter type costs could benefit from some kind of caching. Time based caching seems like the most predicable and non surprising approach to limiting frequency and controlling stale value expectations. There is a caching metric implementation that simply wraps a metric and I believe takes a time parameter for how long to cache it. Why not use that here? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
