[
https://issues.apache.org/jira/browse/STORM-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15396260#comment-15396260
]
ASF GitHub Bot commented on STORM-2006:
---------------------------------------
Github user ptgoetz commented on a diff in the pull request:
https://github.com/apache/storm/pull/1595#discussion_r72513531
--- Diff: conf/defaults.yaml ---
@@ -259,6 +259,10 @@ topology.disruptor.batch.size: 100
topology.disruptor.batch.timeout.millis: 1
topology.disable.loadaware: false
topology.state.checkpoint.interval.ms: 1000
+topology.metrics.aggregate.per.worker: false
--- End diff --
@harshach you are correct, there are no *explicit* interface changes. But
there is an *implicit* contract with existing implementations that expect
`DataPoint.value` to be a specific type, and that contract is broken when this
flag is set to `true`. So this is *effectively* an API change that's just
hidden by the fact that it is configurable.
> Btw, we should try avoiding to address current metrics feature and start
re-designing new metrics feature. To tell the truth, this feature is actually
closer to a hot-fix instead of improvement.
I agree with @HeartSaVioR that this approach is less than optimal and very
brittle. If we're going to break backward compatibility, we should go ahead and
improve the design of the API.
I really don't like the idea that a configuration change can effectively
change an API. I'd rather change the API to be more explicit in terms of data
types sent to the implementation.
> Storm metrics feature improvement: support per-worker level metrics
> aggregation
> -------------------------------------------------------------------------------
>
> Key: STORM-2006
> URL: https://issues.apache.org/jira/browse/STORM-2006
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-core
> Affects Versions: 1.1.0
> Reporter: Jungtaek Lim
> Assignee: Jungtaek Lim
>
> Storm provides per-task level metrics which could be huge when topology has a
> number of tasks.
> Task level metric is useful for determining load balance between tasks, but
> it doesn't need to be time-series fashion.
> Before introducing topology level component like TopologyMaster for JStorm,
> we can utilize SystemBolt to aggregate task level metrics to per-worker level
> metrics.
> We should provide options and this feature should be turned off by default to
> keep backward compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
