Conversation
There was a problem hiding this comment.
@rfecher @rwgdrummer
So when .flush() (or .close()) is called on the StatsCompositionTool instance it goes through the local set of statistics, and pushes them to accumulo.
The problem is there are plenty of statistics which are non idempotent (count being one) - and I don't think there's any realistic way we can require the statistics to be idempotent (it rules it too many).
The problem is any code path which might end up calling .flush() twice (or call a .flush() and later a .close()) will currently trigger multiple evaluations of these.
I would expect calling .flush() multiple times to be safe.
I added a statistics.clear() call here after statistics were flushed; I'm not familiar enough with the rest of the statistics stack to know if this will have other unintended side effects. (It passes testing fine, and in a brief look seemed to be okay.) (had to ad locking around it to ensure what was cleared was the same as what was already persisted).
Added reset to stats tool to clear out entries in error and retain auto-closeable capability merge with master
Fixes for coverity id'd issues
(don't accept this yet, wanted to open this up to discuss a few questions first)
(coverity issues can be seen @ https://scan.coverity.com/projects/3371/view_defects - login required)