[
https://issues.apache.org/jira/browse/STORM-433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14306278#comment-14306278
]
ASF GitHub Bot commented on STORM-433:
--------------------------------------
Github user knusbaum commented on the pull request:
https://github.com/apache/storm/pull/236#issuecomment-72969470
@nathanmarz, @revans2, @d2r
Do we still want this? If so I'll upmerge and fix all the problems:
1. easy, I'll take care of this.
2. I can also monitor the batch-transfer-queue.
3. This one's trickier. It depends on what you mean by "thread-safe." They
are certainly thread-safe in the sense that nothing will get corrupted. I've
read the disruptor code for 2.10.1, and only reads are ever done by the
additional code. They may be off by an amount if a write is done during, but it
won't corrupt any values.
> Give users visibility to the depth of queues at each bolt
> ---------------------------------------------------------
>
> Key: STORM-433
> URL: https://issues.apache.org/jira/browse/STORM-433
> Project: Apache Storm
> Issue Type: Wish
> Reporter: Dane Hammer
> Priority: Minor
>
> I envision being able to browse the Storm UI and see where queues of tuples
> are backing up.
> Today if I see latencies increasing at a bolt, it may not be due to anything
> specific to that bolt, but that it is backed up behind an overwhelmed bolt
> (which has too low of parallelism or too high of latency).
> I would expect this could use sampling like the metrics reported to the UI
> today, and just retrieve data from netty about the state of the queues. I
> wouldn't imagine supporting zeromq on the first pass.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
