NoNodeAvailableException and endless stacktrace in log4j when using TransportClient

Hi all...

The following code, when I attempt to connect to a host that is down,
throws a NoNodeAvailableException.

No problem there - however, in getting to that point ElasticSearch
apparently recurses quite a lot, so that by the time it throws the
Exception, the stack is so deep that log4j complains about it being
too big, and I can't find the actual point of the problem...


try {
TransportClient client = new
TransportClient().addTransportAddress(new
InetSocketTransportAddress(myHost, myPort);

  SearchRequestBuilder builder = client.prepareSearch(index,

docType);
builder.setSearchType(SearchType.DFS_QUERY_THEN_FETCH);
builder.setQuery(new QueryStringQueryBuilder(queryString));
builder.setFrom(startIndex);
builder.setSize(maxResults);
builder.setExplain(true);
ListenableActionFuture future =
builder.execute();
} catch (Throwable t) {
// EXCEPTION HERE
}

If I just System.out.println() the caught exception, I see:
-- org.elasticsearch.client.transport.NoNodeAvailableException: No
node available

or if I call e.printStackTrace(), I see a reasonable-sized stacktrace.

However, if I try to print the stacktrace in log4j, I get:

java.lang.StackOverflowError
at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2826)
at
org.apache.log4j.spi.VectorWriter.println(ThrowableInformation.java:
181)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
67)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)

... ad infinitum.

I'm wondering what the stacktrace contains that might be causing
this... possibly many branching "caused-by" entries? Anyone else seen
this issue with log4j?

  • Tim

Do you have more stack trace when it happens in the log4j? See where the recursion happens?

On Friday, July 8, 2011 at 10:32 PM, TimOnGmail wrote:

Hi all...

The following code, when I attempt to connect to a host that is down,
throws a NoNodeAvailableException.

No problem there - however, in getting to that point Elasticsearch
apparently recurses quite a lot, so that by the time it throws the
Exception, the stack is so deep that log4j complains about it being
too big, and I can't find the actual point of the problem...


try {
TransportClient client = new
TransportClient().addTransportAddress(new
InetSocketTransportAddress(myHost, myPort);

SearchRequestBuilder builder = client.prepareSearch(index,
docType);
builder.setSearchType(SearchType.DFS_QUERY_THEN_FETCH);
builder.setQuery(new QueryStringQueryBuilder(queryString));
builder.setFrom(startIndex);
builder.setSize(maxResults);
builder.setExplain(true);
ListenableActionFuture future =
builder.execute();
} catch (Throwable t) {
// EXCEPTION HERE
}

If I just System.out.println() the caught exception, I see:
-- org.elasticsearch.client.transport.NoNodeAvailableException: No
node available

or if I call e.printStackTrace(), I see a reasonable-sized stacktrace.

However, if I try to print the stacktrace in log4j, I get:

java.lang.StackOverflowError
at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2826)
at
org.apache.log4j.spi.VectorWriter.println(ThrowableInformation.java:
181)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
67)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)

... ad infinitum.

I'm wondering what the stacktrace contains that might be causing
this... possibly many branching "caused-by" entries? Anyone else seen
this issue with log4j?

  • Tim

Unfortunately not - if I do a printStackTrace(), I see a reasonable
stacktrace. But trying to print it with log4j gets the overflow
error.

I'll can post the stacktrace that printStackTrace() returns if that's
any help.

  • Tim

On Jul 8, 2:25 pm, Shay Banon shay.ba...@elasticsearch.com wrote:

Do you have more stack trace when it happens in the log4j? See where the recursion happens?

On Friday, July 8, 2011 at 10:32 PM, TimOnGmail wrote:

Hi all...

The following code, when I attempt to connect to a host that is down,
throws a NoNodeAvailableException.

No problem there - however, in getting to that point Elasticsearch
apparently recurses quite a lot, so that by the time it throws the
Exception, the stack is so deep that log4j complains about it being
too big, and I can't find the actual point of the problem...


try {
TransportClient client = new
TransportClient().addTransportAddress(new
InetSocketTransportAddress(myHost, myPort);

SearchRequestBuilder builder = client.prepareSearch(index,
docType);
builder.setSearchType(SearchType.DFS_QUERY_THEN_FETCH);
builder.setQuery(new QueryStringQueryBuilder(queryString));
builder.setFrom(startIndex);
builder.setSize(maxResults);
builder.setExplain(true);
ListenableActionFuture future =
builder.execute();
} catch (Throwable t) {
// EXCEPTION HERE
}

If I just System.out.println() the caught exception, I see:
-- org.elasticsearch.client.transport.NoNodeAvailableException: No
node available

or if I call e.printStackTrace(), I see a reasonable-sized stacktrace.

However, if I try to print the stacktrace in log4j, I get:

java.lang.StackOverflowError
at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2826)
at
org.apache.log4j.spi.VectorWriter.println(ThrowableInformation.java:
181)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
67)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)

... ad infinitum.

I'm wondering what the stacktrace contains that might be causing
this... possibly many branching "caused-by" entries? Anyone else seen
this issue with log4j?

  • Tim

Got you, but, do you have more data printed as part of the stack overflow failure?

On Monday, July 11, 2011 at 10:50 AM, TimOnGmail wrote:

Unfortunately not - if I do a printStackTrace(), I see a reasonable
stacktrace. But trying to print it with log4j gets the overflow
error.

I'll can post the stacktrace that printStackTrace() returns if that's
any help.

  • Tim

On Jul 8, 2:25 pm, Shay Banon <shay.ba...@elasticsearch.com (http://elasticsearch.com)> wrote:

Do you have more stack trace when it happens in the log4j? See where the recursion happens?

On Friday, July 8, 2011 at 10:32 PM, TimOnGmail wrote:

Hi all...

The following code, when I attempt to connect to a host that is down,
throws a NoNodeAvailableException.

No problem there - however, in getting to that point Elasticsearch
apparently recurses quite a lot, so that by the time it throws the
Exception, the stack is so deep that log4j complains about it being
too big, and I can't find the actual point of the problem...


try {
TransportClient client = new
TransportClient().addTransportAddress(new
InetSocketTransportAddress(myHost, myPort);

SearchRequestBuilder builder = client.prepareSearch(index,
docType);
builder.setSearchType(SearchType.DFS_QUERY_THEN_FETCH);
builder.setQuery(new QueryStringQueryBuilder(queryString));
builder.setFrom(startIndex);
builder.setSize(maxResults);
builder.setExplain(true);
ListenableActionFuture future =
builder.execute();
} catch (Throwable t) {
// EXCEPTION HERE
}

If I just System.out.println() the caught exception, I see:
-- org.elasticsearch.client.transport.NoNodeAvailableException: No
node available

or if I call e.printStackTrace(), I see a reasonable-sized stacktrace.

However, if I try to print the stacktrace in log4j, I get:

java.lang.StackOverflowError
at java.lang.Throwable.getLocalizedMessage(Throwable.java:267)
at java.lang.Throwable.toString(Throwable.java:343)
at java.lang.String.valueOf(String.java:2826)
at
org.apache.log4j.spi.VectorWriter.println(ThrowableInformation.java:
181)
at java.lang.Throwable.printStackTrace(Throwable.java:509)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
67)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)
at
org.apache.log4j.spi.ThrowableInformation.extractStringRep(ThrowableInformation.java:
99)

... ad infinitum.

I'm wondering what the stacktrace contains that might be causing
this... possibly many branching "caused-by" entries? Anyone else seen
this issue with log4j?

  • Tim