accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ed Coleman (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-3329) Consider consolidation of "timing" classes
Date Thu, 21 May 2015 18:18:19 GMT


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:
>             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

View raw message