[
https://issues.apache.org/jira/browse/GIRAPH-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13402729#comment-13402729
]
Eli Reisman commented on GIRAPH-213:
------------------------------------
No, according to netty.io the method used in the NettyClient.stop() is not safe
and can deadlock. They recommend never using it. Even though the future method
looks funky, a read of the docs indicates the futures get their event calls
either way also. So as long as we use the Atomic counter to make sure we don't
release resources before every Future gets its event call, we are safe. I ran
this patch with jobs and also with full 'mvn verify' tests and it seems to work
fine, no problems. Again, its not about the open/closed status of the
connections, its just about when to release the resources, so instant return
from the call doesn't hurt us. Apparently the existing call looks reasonable
(barrier until resources can be released) it is deprecated.
The NettyServer does it too, but at least it sets a timeout per-call. Problem
is, this holds up the return of the call while NOT guaranteeing the connections
are actually closed in time for the resource release, which is bad. There is a
separate ChannelGroupFuture I could use to fix that one too, but I thought I
would start with this one as it had no timeout and deadlock is a bigger risk (I
assume?) than releasing resources before the Channels are guaranteed to be
closed, though neither is good.
Let me know what you decide.
> NettyClient.stop() could deadlock according to netty.io docs
> ------------------------------------------------------------
>
> Key: GIRAPH-213
> URL: https://issues.apache.org/jira/browse/GIRAPH-213
> Project: Giraph
> Issue Type: Improvement
> Affects Versions: 0.2.0
> Reporter: Eli Reisman
> Assignee: Eli Reisman
> Priority: Trivial
> Fix For: 0.2.0
>
> Attachments: GIRAPH-213-1.patch
>
>
> NettyClient.stop() does not follow netty.io best practices and could
> potentially deadlock?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
