[
https://issues.apache.org/jira/browse/HADOOP-9485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13648518#comment-13648518
]
Todd Lipcon commented on HADOOP-9485:
-------------------------------------
Yea, I _think_ we can differentiate between "explicitly set to null" and "not
explicitly set". Either way, I think I'd rather break one or two folks who are
setting to null to get that behavior than have a default against the legacy
blockreader which we'd like to eventually remove.
> inconsistent defaults for hadoop.rpc.socket.factory.class.default
> -----------------------------------------------------------------
>
> Key: HADOOP-9485
> URL: https://issues.apache.org/jira/browse/HADOOP-9485
> Project: Hadoop Common
> Issue Type: Bug
> Components: net
> Affects Versions: 2.0.5-beta
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Priority: Minor
> Attachments: HADOOP-9485.001.patch, HADOOP-9485.002.patch,
> HADOOP-9485.003.patch, HADOOP-9485.004.patch, HADOOP-9485.005.patch,
> HADOOP-9485.006.patch
>
>
> In {{core-default.xml}}, {{hadoop.rpc.socket.factory.class.default}} defaults
> to {{org.apache.hadoop.net.StandardSocketFactory}}. However, in
> {{CommonConfigurationKeysPublic.java}}, there is no default for this key.
> This is inconsistent (defaults in the code versus defaults in the XML files
> should match.) It also leads to problems with {{RemoteBlockReader2}}, since
> the default {{SocketFactory}} creates a {{Socket}} without an associated
> channel. {{RemoteBlockReader2}} cannot use such a {{Socket}}.
> This bug only really becomes apparent when you create a {{Configuration}}
> using the {{Configuration(loadDefaults=true)}} constructor. Thanks to AB
> Srinivasan for his help in discovering this bug.
--
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
