[
https://issues.apache.org/jira/browse/HBASE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449976#comment-16449976
]
Sean Busbey commented on HBASE-20478:
-------------------------------------
bq. why are we calling start_clock 4 times now?
the call to add_vote_table looks at the time since the start_clock when
claiming how long it took to get a given result. In the case where we vote more
than once, that means we're showing a cumulative time taken which results in a
table of times that don't line up with the total time reported at the end.
maybe this means I need to start the clock for each check regardless of success
/ failure. and then save up the time it took for the successes so we get an
accurate total time in the event that it all passes?
given how short a timespan this test usually takes, maybe this is optimizing
early and I should just chuck out cleaning this up while I'm here.
bq. would it make sense to not run each grep twice?
I'm trying to avoid writing output into the results file if there aren't any
issues. given that the test runs in < 1 second I don't think we need to
optimize.
Let me post up v2. I'm having doubts and it's easier to see with things fixed
up.
> precommit check for "hbase antipatterns" should log details and add a footer
> as needed
> --------------------------------------------------------------------------------------
>
> Key: HBASE-20478
> URL: https://issues.apache.org/jira/browse/HBASE-20478
> Project: HBase
> Issue Type: Improvement
> Components: test
> Reporter: Sean Busbey
> Assignee: Sean Busbey
> Priority: Major
> Attachments: HBASE-20478.0.patch, HBASE-20478.1.patch,
> HBASE-20478.WIP.patch
>
>
> came up in discussion on HBASE-20332. our check of "don't do this" things in
> the codebase doesn't log the specifics of complaints anywhere, which forces
> those who want to follow up to reverse engineer the check.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
