[
https://issues.apache.org/jira/browse/STORM-737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14527863#comment-14527863
]
ASF GitHub Bot commented on STORM-737:
--------------------------------------
Github user HeartSaVioR commented on the pull request:
https://github.com/apache/storm/pull/521#issuecomment-98942013
@d2r Thanks for comment, I can wait it. :)
Btw, your branch doesn't follow Nathan's comment.
```
In short, the code in the write-lock is fine – it's the code in the read
lock that needs to be fixed. As part of that, the code looking up the node+port
for a task needs to be moved back to this function and not happen before the
tuple goes on the transfer queue.
```
Root reason is from mk-transfer-fn.
It matches task and node+port but there's some latencies from adding
Transfer queue to sending via Netty. Task to node+port can be changed during
latency so we should delegate matching it to very close to sending, within read
lock to get safely.
So I'd like you to compare mine and yours when you come back. Thanks!
> Workers may try to send to closed connections
> ---------------------------------------------
>
> Key: STORM-737
> URL: https://issues.apache.org/jira/browse/STORM-737
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.9.2-incubating
> Reporter: Derek Dagit
>
> There is a race condition in the worker code that can allow for a send() to
> be called on a closed connection.
> [Discussion|https://github.com/apache/storm/pull/349#issuecomment-87778672]
> The assignment mapping from task -> node+port needs to be read and used in
> the read lock when sending, so that an accurate mapping is used that does not
> include any connections that are closed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
