hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Loughran (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HADOOP-7469) add a standard handler for socket connection problems which improves diagnostics
Date Mon, 18 Jul 2011 14:31:58 GMT
add a standard handler for socket connection problems which improves diagnostics

                 Key: HADOOP-7469
                 URL: https://issues.apache.org/jira/browse/HADOOP-7469
             Project: Hadoop Common
          Issue Type: Sub-task
          Components: util
    Affects Versions:
            Reporter: Steve Loughran
            Priority: Minor

connection refused, connection timed out, no route to host, etc, are classic IOExceptions
that can be raised in a lot of parts of the code. The standard JDK exceptions are useless
for debugging as they 
# don't include the destination (host, port) that can be used in diagnosing service dead/blocked
# don't include any source hostname that can be used to handle routing issues
# assume the reader understands the TCP stack.
It's obvious from the -user lists that a lot of people hit these problems and don't know how
to fix them. Sometimes the source has been patched to insert the diagnostics, but it may be
convenient to have a single method to translate some
SocketException processIOException(SocketException e, String destHost, int destPort) {
  String localhost = getLocalHostname();
  String details = "From "+ localhost +" to "+ desthost + ":"+destPort;
  if (e instanceof ConnectException) {
    return new ConnectException(details 
            + " -- see http://wiki.apache.org/hadoop/ConnectionRefused --" + e, e);
  if (e instanceof UnknownHostException) {
    return new UnknownHostException(details 
            + " -- see http://wiki.apache.org/hadoop/UnknownHost --" + e, e);
  // + handlers for other common socket exceptions
//and a default that returns an unknown class unchanged
  return e;

Testing: try to connect to an unknown host, a local port that isn't live, etc. It's hard to
replicate all failures consistently. It may be simpler just to verify that if you pass in
a specific exception, the string is expanded and the class is unchanged.

This code could then be patched in to places where IO takes place. Note that Http Components
and HttpClient libs already add some destination details on some operation failures, with
their own HttpException tree: it's simplest to leave these alone.

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


View raw message