[ 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