[
https://issues.apache.org/jira/browse/STORM-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Zhong updated STORM-510:
-----------------------------
Issue Type: Sub-task (was: Bug)
Parent: STORM-329
> Netty messaging client blocks transfer thread on reconnect
> ----------------------------------------------------------
>
> Key: STORM-510
> URL: https://issues.apache.org/jira/browse/STORM-510
> Project: Apache Storm
> Issue Type: Sub-task
> Affects Versions: 0.9.2-incubating
> Reporter: Robert Joseph Evans
> Priority: Critical
>
> The latest netty client code will attempt to reestablish the connection on
> failure as part of the send method call. It will block until the connection
> is established or a timeout happens, by default this is about 30 seconds,
> which is also the default tuple timeout.
> This is exacerbated by the read lock that is held during the send, that
> prevents the node->socket mapping from changing while we are sending. This
> is mostly so that we don't close connections while we are trying to write to
> them, which would cause an exception. But this makes it so if there are
> multiple workers on a node that all get rescheduled we will wait the full 30
> seconds to timeout for each worker.
> send must be non-blocking in the current design of the worker, or it will
> prevent other messages from being delivered, and is likely to cause many many
> messages to timeout on a reschedule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
