NoHostAvailableException somewhat opaque


I want to just open up a discussion around the information that NoHostAvailableException typically contains.
We have run into a few situations, where it would have been helpful to have had a bit more information along with a NoHostAvailableException.
There can be different underlying causes and it's somewhat helpful to be pointed in the right direction.

I'm aware of the getErrors() method and yes I suppose one can just catch exceptions and log this call as appropriate.
However in situations where the user has not done this, I feel like a slightly richer default or at least a way of configuring richer output, for production issue scenarios would be helpful.

I see that is a step in the right direction in this respect.
It gives some more information when the number of errors is 3 or fewer, i.e is helpful for small or test clusters when debugging//developing.
(commit 1d6bcd137808257204e02fb2eec0608a2b1d6ad9)

I can see that always shipping all the information for all the errors on a large production cluster is both potentially somewhat verbose and maybe a little risky (might make certain failure scenarios worse?).

Could we maybe allow that hardcoded 3 to be configurable?
Or perhaps always ship the first X errors? (This could also be confusing if not all the errors are the same.)

If you're handling this differently or think it I have missed something please let me know, from what I've heard people mostly seem to be catching + logging getErrors().

Other ideas around how to make this more helpful are naturally appreciated.


redhat 6

Pull Requests



Matt Byrd
August 8, 2014, 9:37 PM

This seems like a good compromise.
It should be enough information to help in the majority of cases.
As long as the error message is clear about the errors which are being displayed
and those that are not and how to get them, it shouldn’t cause confusion.

Olivier Michallat
November 28, 2014, 10:50 AM

Done. I've also added a getCustomMessage method that builds tailored messages (configurable number of errors, formatting, include stack traces), to reduce the need for client code to process getErrors() explicitly.

Pierre Laporte
December 13, 2014, 5:35 PM

I have verified the code and although it is correct, I am concerned with getCustomMessage and the two extra booleans added as last parameters of makeMessage.

The new default message now has useful information and will be "nicely" printed by most logging frameworks (no newline character). To me, this part is good.

However, the getCustomMessage method feels like a bad foreach loop around getErrors(), where we decide the acceptable formats for our users. I can't see a real (valuable) difference between getCustomMessage(false, true) and getCustomMessage(true, true), so I am wondering whether that first parameter is useful and whether that combination makes sense.

I suggest to remove getCustomMessage from the public API as I don't see the value of that method.

Olivier Michallat
December 16, 2014, 10:03 AM

The two boolean parameters encode 3 cases:

  1. not formatted (single line, no stack traces).

  2. formatted (one host per line for better readability), without stack traces.

  3. formatted, with stack traces.

I agree that getCustomMessage does not bring a lot compared to what a user can implement in their application. However I think people will often need it, so it makes sense to provide it as a convenience.

Pierre Laporte
December 16, 2014, 2:19 PM

Not sure it will be used...

As a developer, to prevent my logfiles from having unparseable log messages, I would probably only use a method that return content on a single line. Of course, in case of exceptions, the common use indicates that one can have stacktraces after a log message. But I have never seen text messages between exception stacktraces unless those message were formatted according to the logger format.

This is not a really big issue, so I agree to mark this as resolved.



Pierre Laporte


Matt Byrd


PM Priority


Affects versions

Fix versions

Pull Request


Doc Impact




External issue ID


External issue ID