improve the startup error message when a box can't resolve its own hostname

If a linux/unix box can't resolve its assigned hostname, I get weird cryptic mule errors starting Mirth:

root@stevek_zone:/opt/mirth# hostname stevek_zone root@stevek_zone:/opt/mirth# ping stevek_zone ping: unknown host stevek_zone

INFO | jvm 1 | 2008/04/29 12:10:56 | ERROR 2008-04-29 12:10:56,548 [Thread-0] org.mule.impl.model.seda.SedaModel: Error starting component [823699bf-6257-481c-8c8a-5ade277994fa] INFO ]( jvm 1 | 2008/04/29 12:10:56 | org.mule.providers.FatalConnectException: ReconnectStrategy "org.mule.providers.SingleAttemptConnectionStrategy" failed to reconnect receiver on endpoint "mllp://127.0.0.1:9104"

I used jdb to eventually discover this:

Thread-0[1) print e e = "java.net.UnknownHostException: stevek_zone: stevek_zone"

Now, a properly set up box would always have its host name be resolvable. But I'm testing Solaris Zones and by default it was not. The fix is simply to add the hostname to the localhost entry in /etc/hosts:

127.0.0.1 localhost stevek_zone

Is there any way to make the exception printed out in the log a bit more descriptive? The originall UnknownHostException got hidden somewhere.

Gerald adds:

I looked at the code for the MLLP receiver (at the doConnect method), and it looks like we throw a general Mule ConnectException when an error occurs. I assume that this exception encapsulates and obscures the underlying UnknownHostException that you discovered. When you get a chance, go ahead and open an issue to expand the stack trace that is printed on the doConnect methods for any of the connectors that might have this problem (TCP, HTTP, etc.) and we'll get it in the next release.

Thanks!

Imported Issue. Original Details: Jira Issue Key: MIRTH-863 Reporter: steven_kehlet Created: 2008-07-02T10:42:49.000-0700

rbeckman-nextgen / test-mc4

improve the startup error message when a box can't resolve its own hostname #844