[
https://issues.apache.org/jira/browse/STORM-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16421019#comment-16421019
]
Roshan Naik edited comment on STORM-2983 at 3/30/18 10:26 PM:
--------------------------------------------------------------
Removing / preserving the optimization will not address the core problem ...
which is .. topology.workers is not usable and therefore any code
(present/future) would be considered broken with no workaround.
There are other use cases in code for this setting plus more that I can think
of, but to limit the scope I will stay with the topic of some settings in
topoConf being unreliable. I dont think its a good idea to say any such code
should not allowed in storm.
Since topoConf is part of the API ... it is surprising to know that any
setting stored in it cannot be relied upon. The
[documentation|http://storm.apache.org/releases/1.2.1/Configuration.html]
specifically states that the system supports overriding settings. *The actual
bug here is that we are not dynamically overriding the setting to what it
should be.*
I think we need to have a good justification for making any setting unreliable
and not open the door for more of the same.
Would like to know:
- Is there good reason why this setting cannot be made reliable ?
- Are you aware of other such settings that are not reflecting the correct
values ?
was (Author: roshan_naik):
Removing / preserving the optimization will not address the core problem ...
which is .. topology.worker.count is not usable and therefore any code
(present/future) would be considered broken with no workaround.
There are other use cases in code for this setting plus more that I can think
of, but to limit the scope I will stay with the topic of some settings in
topoConf being unreliable. I dont think its a good idea to say any such code
should not allowed in storm.
Since topoConf is part of the API ... it is surprising to know that any
setting stored in it cannot be relied upon. The
[documentation|http://storm.apache.org/releases/1.2.1/Configuration.html]
specifically states that the system supports overriding settings. *The actual
bug here is that we are not dynamically overriding the setting to what it
should be.*
I think we need to have a good justification for making any setting unreliable
and not open the door for more of the same.
Would like to know:
- Is there good reason why this setting cannot be made reliable ?
- Are you aware of other such settings that are not reflecting the correct
values ?
> Some topologies not working properly
> -------------------------------------
>
> Key: STORM-2983
> URL: https://issues.apache.org/jira/browse/STORM-2983
> Project: Apache Storm
> Issue Type: Bug
> Reporter: Ethan Li
> Assignee: Ethan Li
> Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For example,
> {code:java}
> bin/storm jar storm-loadgen-*.jar
> org.apache.storm.loadgen.ThroughputVsLatency --spouts 1 --splitters 2
> --counters 1 -c topology.debug=true
> {code}
> on ResourceAwareScheduler not working properly.
> With default cluster settings, there will be only one __acker-executor and it
> will be on a separate worker. And it looks like the __acker-executor was not
> able to receive messages from spouts and bolts. And spouts and bolts
> continued to retry sending messages to acker. It then led to another problem:
> STORM-2970
> I tried to run on storm right before
> [https://github.com/apache/storm/pull/2502] and right after and confirmed
> that this bug should be related to it
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
