Elastic Java client returns different result from HTTP API

Question

I have an application that uses the Elasticsearch Java API (5.6.7) to execute aggregation request (conditions). I created the following search document using curl and the HTTP API (relevant information is displayed):

{ "from" : 0, "size" : 0, "sort" : [ { "@timestamp" : { "order" : "desc" } } ], "aggregations" : { "level" : { "terms" : { "field" : "level.keyword", "size" : 10, "min_doc_count" : 1, "shard_min_doc_count" : 0, "show_term_doc_count_error" : false, "order" : [ { "_count" : "desc" }, { "_term" : "asc" } ] } } } } 

Now that the request has been implemented in my Java program, I notice that the results are different from the HTTP API results

.

Both return exactly the same meta-information regarding fragments, number of hits, etc .:

 { "took": 1, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": 3659, "max_score": 0.0, "hits": [ ] } 

However, the returned aggregation from the Java API does not contain any buckets:

  "aggregations": { "level": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ ] } 

while the same aggregation from the HTTP API does contains buckets:

  "aggregations": { "level": { "doc_count_error_upper_bound": 0, "sum_other_doc_count": 0, "buckets": [ { "key": "INFO", "doc_count": 2691 }, { "key": "WARN", "doc_count": 776 }, { "key": "ERROR", "doc_count": 192 } ] } 

I am 100% sure that the search document is the same (copied from the Java application log).

Q: What can cause this difference?

EDIT My Java code to build a query (contains many links to other classes):

  // Start building the search itself SearchRequestBuilder srch = client.prepareSearch(indices.toArray(new String[indices.size()])) .setTypes(types.toArray(new String[types.size()])).setFrom(0).setSize(0); // Conditional sort order if (t.getOrder() != null) srch.addSort(t.getOrder().getBuilder()); // Add aggregationbuilders to this search for (NivoStatistic stat : t.getStatistics()) { logger.log(Level.FINER, "Adding statistic {0}", stat.getName()); srch.addAggregation(stat.getContent()); } // Use a search template NivoQuery qry = t.getQuery(); SearchTemplateRequestBuilder srchTemplate = new SearchTemplateRequestBuilder(client) .setRequest(srch.request()) .setScript(qry.getTemplateString()) .setScriptType(ScriptType.INLINE) .setScriptParams(qry.getParameterValues()) ; logger.log(Level.FINER, "Prepared search: {0}", srchTemplate.request().getRequest().toString()); 

Exiting the last log statement is what I use for POST via curl -XPOST http://localhost:9200/...

Then execution is done through

  // Execute the search try { SearchResponse resp = srchTemplate.get().getResponse(); logger.log(Level.FINER, "Search returned: {0}", resp.toString()); if (resp.status() == RestStatus.OK && resp.getAggregations() != null) { for (Aggregation agg : resp.getAggregations().asList()) { // Update response t.getResponse().addStat(new NivoStatsHit(agg)); } } } catch (ElasticsearchException e) { throw new ApiException(ApiExceptionCode.SEARCH_10061, "Database error: " + e.getDetailedMessage()); } 

Answer 1

I started testing my code with Elasticserach 5.6.3, and although it looked doable at first, I realized that it wasn’t that simple. And it all seems to come down to finding the use of patterns.

The main thing is that your code is that you use search patterns in conjunction with aggregates. In my tests, even size and from ;-) did not work either. Not sure how this worked for you. Or maybe you did not understand that the result will also help you return the documents themselves, since this does not apply to your message. The query you are registering looks correct, but the results show that the aggregations of size and from ignored.

So, at this point I began to study why search patterns and aggregations do not work (fyi, resp.getAggregations() returns null ). And I found this - https://github.com/elastic/elasticsearch/issues/22766 .

I tried to combine the search template builder with a regular search query, but I failed.