You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2015/10/01 21:17:26 UTC
[jira] [Commented] (STORM-1078) RateTracker.java is not thread safe
[ 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 <ev...@yahoo-inc.com>
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)