[SPARK-4475] change "localhost" to "127.0.0.1" if "localhost" can't be resolved

[lvsoft]

This will fix [SPARK-4475]

Simply change "localhost" to equivalent "127.0.0.1" will solve the issue.

[AmplabJenkins]

Can one of the admins verify this patch?

[davies]

@lvsoft There are many cases that will fail if localhost can not be resolved. Does spark work totally well after this fix (such as webui)?

[lvsoft]

I did a doctest in aggregation.py to confirm this fix is OK if localhost can not be resolved. However, I'm not fully confident that spark will work well totally in such situation. And I also don't think a node is proper configured if localhost can not be resolved.

However, I think 127.0.0.1 should always be used in local communication rather than localhost, which can provide better suitability, without introducing any shortages. After all, make things right in the right situation is trivial, while make things right in a tolerable wrong situation is more difficult and more meaningful, which is what we are working hard for.

If you agreed with that, I can do a further check to eliminate all related localhost in spark.

[davies]

@lvsoft I agreed that 127.0.0.1 is better than localhost in some cases, if it will not work in the case of the machines only have IPv6, which happens in Facebook.

In the first beginning, I did something as you have done, but after some digging, it seems that there are many occurs of localhost in the codebase, then think about that maybe fix localhost (make it resolvable) is better to replace it as 127.0.0.1, there are many software depend on it.

[srowen]

What was the outcome here? I can't claim to be an expert, but, obviously localhost is a symbolic name and that's generally the right thing to use to mean "the local machine", whereas 127.0.0.1 always means an IPv4 endpoint reached by TCP. The potential extra name resolution time isn't an issue here. When would localhost not resolve?

FWIW the SocketServer example in Python docs uses localhost (https://docs.python.org/2/library/socketserver.html). Most of Spark does too, but, I see an example in the Python code in daemon.py where a process listens on 127.0.0.1.

Leave it unless there is a problem?

[srowen]

I suggest closing this unless we can point to a clear reason to prefer 127.0.0.1.

[srowen]

Mind closing this PR? I'm not seeing a clear argument for changing this given the tradeoffs, and that Python examples don't use 127.0.0.1.