[
https://issues.apache.org/jira/browse/ACCUMULO-3329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14554791#comment-14554791
]
Ed Coleman commented on ACCUMULO-3329:
--------------------------------------
One case where I found start being called multiple times is
org.apache.accumulo.test.NativeMapStressTest in testLotsOfGetsAndScans().
The main thing that was giving me pause is that most stop watch implementations
will throw an illegal state exception if start is called on a running instance,
while OpTimer just increments the operation counter and sets the internal time
to the current time (overwriting any previous "start time", which I could be
persuaded is a bug.)
My current intention is to replace our usage of OpTimer with something that
will allow migration, with the short term goal to remove log4j Level.
Replicating our current behavior is not difficult, but I worry about
introducing anything that would start throwing new exceptions - and in case
anyone is using the current behavior. I don't believe that
org.apache.accumulo.core.util is considered as part of the public API, but I
also don't see a reason to cause unnecessary churn when it can be avoided
(especially until 2.0 is finalized.)
So, I really default to an incremental, small step approach. I should have a
patch as a straw man for comments soon.
> 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.8.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)
