hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Hansen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-10311) libhdfs++: DatanodeConnection::Cancel should not delete the underlying socket
Date Thu, 21 Apr 2016 12:30:26 GMT

    [ https://issues.apache.org/jira/browse/HDFS-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15251814#comment-15251814
] 

Bob Hansen commented on HDFS-10311:
-----------------------------------

SafeDisconnect should log some details at DEBUG level if there was an exception during disconnect;
it's the kind of thing we may want to know.  

SocketDeleter doesn't need to check if the socket is open; SafeDisconnect does that for you.

Holding an internal lock during a callback is generally an anti-pattern (unless the lock it
solely to serialize callbacks, and even then it's dangerous).  If the callback consumer attempts
to call back into the object or destroy it, you're going to have a deadlock or a segfault.
 We should look at the lock in DataNodeConnectionImpl a little more closely.









> libhdfs++: DatanodeConnection::Cancel should not delete the underlying socket
> -----------------------------------------------------------------------------
>
>                 Key: HDFS-10311
>                 URL: https://issues.apache.org/jira/browse/HDFS-10311
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs-client
>            Reporter: James Clampffer
>            Assignee: James Clampffer
>         Attachments: HDFS-10311.HDFS-8707.000.patch, HDFS-10311.HDFS-8707.001.patch
>
>
> DataNodeConnectionImpl calls reset on the unique_ptr that references the underlying asio::tcp::socket.
 If this happens after the continuation pipeline checks the cancel state but before asio uses
the socket it will segfault because unique_ptr::reset will explicitly change it's value to
nullptr.
> Cancel should only call shutdown() and close() on the socket but keep the instance of
it alive.  The socket can probably also be turned into a member of DataNodeConnectionImpl
to get rid of the unique pointer and simplify things a bit.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message