[ 
https://issues.apache.org/jira/browse/HDFS-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

bc Wong updated HDFS-941:
-------------------------

    Attachment: HDFS-941-5.patch

Greatly simplified the socket cache.

* Sam, thanks for the MapMaker pointer. It looks really useful. But I need a 
multimap, which the MapMaker doesn't support. (But I found the multimap library 
in the same place.)
* The socket cache also needs to close the sockets when it evicts them, which 
makes it socket specific unfortunately.
* I'm aware of the giant lock in the cache. This is what I don't know: Will 
there be high contention? I assume that most of the time, clients are doing i/o 
or processing the data read, that the synchronization overhead here is 
relatively small. We could do finer grain locking, but I don't want to optimize 
something that's not gonna be a bottleneck.



> Datanode xceiver protocol should allow reuse of a connection
> ------------------------------------------------------------
>
>                 Key: HDFS-941
>                 URL: https://issues.apache.org/jira/browse/HDFS-941
>             Project: Hadoop HDFS
>          Issue Type: Improvement
>          Components: data-node, hdfs client
>    Affects Versions: 0.22.0
>            Reporter: Todd Lipcon
>            Assignee: bc Wong
>         Attachments: HDFS-941-1.patch, HDFS-941-2.patch, HDFS-941-3.patch, 
> HDFS-941-3.patch, HDFS-941-4.patch, HDFS-941-5.patch
>
>
> Right now each connection into the datanode xceiver only processes one 
> operation.
> In the case that an operation leaves the stream in a well-defined state (eg a 
> client reads to the end of a block successfully) the same connection could be 
> reused for a second operation. This should improve random read performance 
> significantly.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to