accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Elser (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3840) Refactor OpTimer so that it does not use log4j logger.
Date Fri, 22 May 2015 18:39:18 GMT

    [ https://issues.apache.org/jira/browse/ACCUMULO-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14556589#comment-14556589
] 

Josh Elser commented on ACCUMULO-3840:
--------------------------------------

bq. One thing that I did notice is that OpTimer is only ever used at TRACE level (except for
a test case) - even in a place or two where the comments say that for performance, logging
should not be done. - That would seem to indicate that tracing would not be appropriate at
that level and may for all of OpTimer usages.

Oh interesting. That's a fun comment. I imagine a bit of work to go into _good_ instrumentation.
We have it sprinkled around, but could likely benefit from a planned visitation of the public
API impl.

bq. Are you thinking nanoTime instead of currentTimeMillis? I thought about borrowing the
Guava StopWatch / Ticker to approach to allow us to swap time sources, but then figured that
it would be superseded by tracing and that nanos where unnecessary with the precision that
we need and the fact that these are hardly ever used.

I remember reading something about how using nanoTime was better than currentTimeMillis for
timings. Maybe it was https://blogs.oracle.com/dholmes/entry/inside_the_hotspot_vm_clocks

{quote}
If you are interested in measuring absolute time then always use System.currentTimeMillis().
Be aware that its resolution may be quite coarse (though this is rarely an issue for absolute
times.)

If you are interested in measuring/calculating elapsed time, then always use System.nanoTime().
On most systems it will give a resolution on the order of microseconds. Be aware though, this
call can also take microseconds to execute on some platforms. 
{quote}

The only other thing I'd request is to try to keep OpTimer/StopWatch improvements and consolidations
as separate as possible from the log4j/slf4j switchover. We don't have a hard rule for one-change-per-commit,
but it definitely helps if you can do that.

> Refactor OpTimer so that it does not use log4j logger.
> ------------------------------------------------------
>
>                 Key: ACCUMULO-3840
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3840
>             Project: Accumulo
>          Issue Type: Sub-task
>          Components: build
>    Affects Versions: 1.6.2, 1.7.0
>            Reporter: Ed Coleman
>            Assignee: Ed Coleman
>            Priority: Minor
>             Fix For: 1.8.0
>
>         Attachments: ACCUMULO-3840.patch
>
>
> OpTimer currently uses log4j specific classes. OpTimer and the callers can be modified
so that log4j dependencies are not required.
> The evaluation of timer consolidation raised in ACCUMULO-3329 can still be performed.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message