[
https://issues.apache.org/jira/browse/STORM-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14387126#comment-14387126
]
ASF GitHub Bot commented on STORM-593:
--------------------------------------
Github user nathanmarz commented on the pull request:
https://github.com/apache/storm/pull/349#issuecomment-87778672
Looking inside task->node+port needs to be done inside the read lock (as it
was done before this TaskDrainer class got inserted here). If that's done,
there's no possible way for the sender to get its hands on a connection that's
closed or going to be closed while it's using it.
To elaborate on that last point: once the write lock code is finished, all
entries in task->node+port are up to date and accurate, and no connections for
those node+ports will be closed. This means it's impossible for the code in
read-locked to get a to-be-closed connection since it gets everything by
looking at task->node+port first.
The write-locked code was carefully written this way to minimize the amount
of work that actually happens in the write lock. This is important because when
that code is active, tasks are prevented from sending messages. The way it is
now, it's just setting the value of a single in-memory atom – so basically no
work at all. If it were making/closing connections, it would be a completely
different story.
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.
> No need of rwlock for clojure atom
> -----------------------------------
>
> Key: STORM-593
> URL: https://issues.apache.org/jira/browse/STORM-593
> Project: Apache Storm
> Issue Type: Improvement
> Affects Versions: 0.10.0
> Reporter: xiajun
> Assignee: xiajun
>
> cached-node+port->socket in worker-data is atom, there on need for rwlock
> endpoint-socket-lock to protect cached-node+port->socket. And after use
> rwlock, there will be competition between refresh-connections and message
> send.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
