You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Ed Coleman (JIRA)" <ji...@apache.org> on 2015/03/27 11:15:52 UTC
[jira] [Commented] (ACCUMULO-3329) Consider consolidation of
"timing" classes
[ https://issues.apache.org/jira/browse/ACCUMULO-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14383619#comment-14383619 ]
Ed Coleman commented on ACCUMULO-3329:
--------------------------------------
OpTimer is one of the classes that explicitly sets the logging level. I was going to look into re-factoring OpTimer so that it would not have a direct dependency on log4j.
I will keep this ticket in mind and see if maybe we can get rid of OpTimer altogether by using one of the other suggestions.
> Consider consolidation of "timing" classes
> ------------------------------------------
>
> Key: ACCUMULO-3329
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3329
> Project: Accumulo
> Issue Type: Improvement
> Components: client, master, tserver
> Reporter: Josh Elser
> Labels: newbie
> Fix For: 1.7.0
>
>
> We have a number of "timing" classes in or used by the codebase
> * org.apache.accumulo.core.util.StopWatch
> * org.apache.accumulo.core.util.OpTimer
> * Traces
> * Guava's Stopwatch
> I'm assuming that consolidation of all of the timings into Traces would be the best (assuming that if we care about the timing of a given operation implies that we would also care about the timing of the "bigger picture").
> If we can remove some of our timer classes, that would be great. Not suggesting that we forcibly prevent the use of Stopwatches/TImers in the codebase entirely -- just where it makes sense.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)