[
https://issues.apache.org/jira/browse/STORM-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15011248#comment-15011248
]
ASF GitHub Bot commented on STORM-956:
--------------------------------------
Github user revans2 commented on the pull request:
https://github.com/apache/storm/pull/647#issuecomment-157757168
I personally can see both sides of this. There are situations where a
bolt/spout may be hung because of a bug, like a thread deadlock in some
external client, and restarting the worker will fix the issue. But I agree
that this should be a very rare situation.
I don't get the argument that this is expensive if we get it wrong. We
already fail fast if some bolt or spout throws an unexpected exception. I
don't see this being that different.
A bolt or spout not able to process anything for 5 mins seems like an OK
time to see if we can restart things, especially for a low latency framework.
I personally am +1 on the concept of having timeouts. I would like to see some
changes to the implementation of this patch, but there is no reason to go into
that if @kishorvpatil has a -1 on even the idea of it. @kishorvpatil and
@bastiliu have I swayed you at all with my argument?
> When the execute() or nextTuple() hang on external resources, stop the
> Worker's heartbeat
> -----------------------------------------------------------------------------------------
>
> Key: STORM-956
> URL: https://issues.apache.org/jira/browse/STORM-956
> Project: Apache Storm
> Issue Type: Improvement
> Components: storm-core
> Reporter: Chuanlei Ni
> Assignee: Chuanlei Ni
> Priority: Minor
> Original Estimate: 6h
> Remaining Estimate: 6h
>
> Sometimes the work threads produced by mk-threads in executor.clj hang on
> external resources or other unknown reasons. This makes the workers stop
> processing the tuples. I think it is better to kill this worker to resolve
> the "hang". I plan to :
> 1. like `setup-ticks`, send a system-tick to receive-queue
> 2. the tuple-action-fn deal with this system-tick and remember the time that
> processes this tuple in the executor-data
> 3. when worker do local heartbeat, check the time the executor writes to
> executor-data. If the time is long from current (for example, 3 minutes), the
> worker does not do the heartbeat. So the supervisor could deal with this
> problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
