[
https://issues.apache.org/jira/browse/STORM-1078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14940262#comment-14940262
]
ASF GitHub Bot commented on STORM-1078:
---------------------------------------
GitHub user revans2 opened a pull request:
https://github.com/apache/storm/pull/776
STORM-1078: Updated RateTracker to be thread safe
, more accurate, and very fast. Removed sub-sampling of rate calculation in
disruptor, because sub-sampling was more expensive than just doing the
calculation.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/revans2/incubator-storm STORM-1078
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/storm/pull/776.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #776
----
commit dbcb138603f55fc9f234d2d3b2404a2bfc92e4d9
Author: Robert (Bobby) Evans <[email protected]>
Date: 2015-10-01T18:00:51Z
Updated RateTracker to be thread safe, more accurate, and very fast.
removed subsampling of rate calculation in disruptor, because sub-sampling was
more expensive than just doing the calculation.
----
> RateTracker.java is not thread safe
> -----------------------------------
>
> Key: STORM-1078
> URL: https://issues.apache.org/jira/browse/STORM-1078
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-core
> Affects Versions: 0.11.0
> Reporter: Robert Joseph Evans
> Assignee: Robert Joseph Evans
>
> The RateTracker class is not thread safe at all. It may not be that big of a
> deal, but the rates will be off if we notify from multiple threads, like we
> do with disruptor. It also has the potential to be way off if notify is
> being called at the same time as updateSlides. This would result in the new
> bucket not being set to 0, but getting the old value that was there
> previously.
> We want to be very careful that what we do does not impact the performance
> too much. So ideally no big locks but use AtomicLongs instead.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
