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.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---