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

Ming Ma commented on HDFS-5175:
-------------------------------

Thanks, [~wheat9]. Here are some investigations regarding the solution for 
webHDFS.

1. SSLSocketFactory approach doesn't work for regular http, given it requires 
HttpsURLConnection.
2. Socket.setSocketFactroy() for the entire JVM works if you only need to set 
DSCP based on remote address and port. But there is no way to config different 
DSCP values for different sockets.
3. There might be a way to get to the private socket instance of 
HttpURLConnection. But that is really hack.

So with all these, httpclient seems to be most elegant approach, specifically  
org.apache.http.client. It appears HDFS chose to use URLConnection to manage 
connections. Appreciate if others can provide some context if httpclient has 
been considered.

1. Development effort at https://github.com/apache/httpclient is quite active.
2. HADOOP-10105 explained httpclient is end of life. But that seems to refer to 
org.apache.commons.httpclient.


> Provide clients a way to set IP header bits on connections
> ----------------------------------------------------------
>
>                 Key: HDFS-5175
>                 URL: https://issues.apache.org/jira/browse/HDFS-5175
>             Project: Hadoop HDFS
>          Issue Type: Bug
>    Affects Versions: 2.0.5-alpha
>            Reporter: Lohit Vijayarenu
>
> It would be very helpful if we had ability for clients to set IP headers when 
> they make socket connections for data transfers. We were looking into setting 
> up QoS using DSCP bit and saw that there is no easy way to let clients pass 
> down a specific value when clients make connection to DataNode.
> As a quick fix we did something similar to io.file.buffer.size where client 
> could pass down DSCP integer value and when DFSClient opens a stream, it 
> could set the value on socket using setTrafficClass
> Opening this JIRA to get more inputs from others who have had experience and 
> might have already thought about this. 



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

Reply via email to