hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Patrick McCabe (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-4353) Encapsulate connections to peers in Peer and PeerServer classes
Date Fri, 04 Jan 2013 02:08:12 GMT

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

Colin Patrick McCabe commented on HDFS-4353:

bq. did this timeout setting (just after the newPeer call) get lost in the refactor?

Originally: read timeout set in {{newSocket}}, write timeout set in {{BlockReaderFactory#newBlockReader}}
Now: both timeouts set in {{BlockReaderFactory#newBlockReader}}

bq. peer.getOutputStream here calls new SocketOutputStream(channel, 0) – ie doesn't set
a write timeout. However, the previous code here did set a write timeout. Does this turn out
to not matter due to another call later?

{{DataXceiverServer#run}} sets a write timeout on the peer before passing it to {{DataXceiver}}.
 However, {{DataXceiver}} plays with the write timeout a lot.  I suppose we could move the
write timeout into {{DataXceiver}} too, just to keep them in the same place.

[test failures]

* Looks like I have to put the "disable peer cache" test into a separate junit test, due to
our use of a singleton here.

Also, {{LinkedListMultimap}} never calls {{equals}} at all, it seems, so I can leave off that
> Encapsulate connections to peers in Peer and PeerServer classes
> ---------------------------------------------------------------
>                 Key: HDFS-4353
>                 URL: https://issues.apache.org/jira/browse/HDFS-4353
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: datanode, hdfs-client
>    Affects Versions: 2.0.3-alpha
>            Reporter: Colin Patrick McCabe
>            Assignee: Colin Patrick McCabe
>         Attachments: 02b-cumulative.patch, 02-cumulative.patch
> Encapsulate connections to peers into the {{Peer}} and {{PeerServer}} classes.  Since
many Java classes may be involved with these connections, it makes sense to create a container
for them.  For example, a connection to a peer may have an input stream, output stream, readablebytechannel,
encrypted output stream, and encrypted input stream associated with it.
> This makes us less dependent on the {{NetUtils}} methods which use {{instanceof}} to
manipulate socket and stream states based on the runtime type.  it also paves the way to introduce
UNIX domain sockets which don't inherit from {{java.net.Socket}}.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message