You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "Rick Kellogg (JIRA)" <ji...@apache.org> on 2015/10/09 02:18:26 UTC

[jira] [Updated] (STORM-33) Log warning if number of un-acked tuples in a bolt gets too large

     [ https://issues.apache.org/jira/browse/STORM-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Kellogg updated STORM-33:
------------------------------
    Component/s: storm-core

> Log warning if number of un-acked tuples in a bolt gets too large
> -----------------------------------------------------------------
>
>                 Key: STORM-33
>                 URL: https://issues.apache.org/jira/browse/STORM-33
>             Project: Apache Storm
>          Issue Type: Improvement
>          Components: storm-core
>            Reporter: James Xu
>
> https://github.com/nathanmarz/storm/issues/162
> This is a common application bug, so it would be nice if Storm helped out in tracking these down.
> -----------------------------------------------------------------------------------------------------
> ghost : is there a definition of too large? Heap consumption? Retrieval/Insert cost?
> Obviously configuration tracked would be preferred, but I'm trying to get a feel for the nature of the problem. And its causes? It seems that we are mostly talking about compute costs 'downstream' since most other anomalies would fall into the category of (unforeseen or anomalous) capacity planning.
> Is this issue the start of a dynamic/adaptive scheduling fix for exceptional compute costs? Something like RTRebal?
> -----------------------------------------------------------------------------------------------------
> ghost: Ok. I made it through several other issues. fwiw, ignore the question about RTRebal :-) Its a recurring documented issue in several places; not sure issue is the right term .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)