[
https://issues.apache.org/jira/browse/STORM-636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14293889#comment-14293889
]
ASF GitHub Bot commented on STORM-636:
--------------------------------------
Github user d2r commented on a diff in the pull request:
https://github.com/apache/storm/pull/392#discussion_r23628156
--- Diff: storm-core/src/storm.thrift ---
@@ -243,6 +243,16 @@ struct SubmitOptions {
2: optional Credentials creds;
}
+enum NumErrorsChoice {
+ ALL,
+ NONE,
+ ONE
+}
+
+struct GetInfoOptions {
+ 1: optional NumErrorsChoice num_err_choice;
--- End diff --
I should add, the current ZK storage of errors isn't very flexible. We
store at most 10 errors per component (hard-coded). With only 10 errors to
work with, I am not sure how much more flexibility we get by doing pagination.
I guess this hard-coded limit of 10 is why I did not pursue pagination—it is
just easier to give all 10 errors in the case that we want more than 1.
> UI/Monitor is slow for topologies with a large number of components
> -------------------------------------------------------------------
>
> Key: STORM-636
> URL: https://issues.apache.org/jira/browse/STORM-636
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.10.0
> Reporter: Derek Dagit
> Assignee: Derek Dagit
> Priority: Minor
>
> The getTopologyInfo method in nimbus fetches from ZK all errors reported by
> all components. This becomes too slow for topologies with a larger numbers
> of components (bolts/spouts).
> In one example, the UI consistently took over 5 minutes to load the topology
> page for a topology with nearly 500 components while ZK was under load.
> Errors are currently stored in ZooKeeper under individual znodes per
> component. This means that each call to getTopologyInfo needs to list
> children of each znode and then download the error znodes it finds.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
