[date_histogram aggregation] OutOfMemoryError when using "time_zone" attribute

[boillodmanuel]

Elasticsearch version : 1.2.2
Operation : date_histogram aggregation

In date_histogram aggregation (documentation), when I use the "time_zone" attribute, I have an OutOfMemoryError (see response below).

{
   "error": "ReduceSearchPhaseException[Failed to execute phase [fetch], [reduce] ]; nested: OutOfMemoryError[Java heap space]; ",
   "status": 503
}

The complete stacktrace is:

[2014-07-22 19:01:15,800][DEBUG][action.search.type       ] [Briquette] failed to reduce search
org.elasticsearch.action.search.ReduceSearchPhaseException: Failed to execute phase [fetch], [reduce] 
    at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.finishHim(TransportSearchQueryThenFetchAction.java:140)
    at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$1.onResult(TransportSearchQueryThenFetchAction.java:112)
    at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction$1.onResult(TransportSearchQueryThenFetchAction.java:106)
    at org.elasticsearch.search.action.SearchServiceTransportAction$23.run(SearchServiceTransportAction.java:526)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:724)
Caused by: java.lang.OutOfMemoryError: Java heap space
    at org.elasticsearch.search.aggregations.bucket.histogram.InternalDateHistogram.createBucket(InternalDateHistogram.java:146)
    at org.elasticsearch.search.aggregations.bucket.histogram.InternalDateHistogram.createBucket(InternalDateHistogram.java:36)
    at org.elasticsearch.search.aggregations.bucket.histogram.InternalHistogram.reduce(InternalHistogram.java:324)
    at org.elasticsearch.search.aggregations.InternalAggregations.reduce(InternalAggregations.java:140)
    at org.elasticsearch.search.controller.SearchPhaseController.merge(SearchPhaseController.java:545)
    at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.innerFinishHim(TransportSearchQueryThenFetchAction.java:151)
    at org.elasticsearch.action.search.type.TransportSearchQueryThenFetchAction$AsyncAction.finishHim(TransportSearchQueryThenFetchAction.java:138)
    ... 6 more

Query detail :

POST index/type/_search
{
  "query": {
    "filtered": {
      "query": {
        "match_all": {}
      }
    }
  },
  "aggregations": {
    "tendance": {
      "date_histogram": {
        "field": "date_creation",
        "interval": "month",
        "min_doc_count": 0,
        "time_zone": 1,
        "extended_bounds": {
          "min": "2013-01-01T00:00:00.000+01:00",
          "max": "2013-01-31T23:59:59.999+01:00"
        }
      }
    }
  }
}

With "time_zone": "Europe/Paris", I have the same error.
With "time_zone": 0, everything is good and the query tooks 19ms.

The document mapping is:

"mappings":{  
      "marche_prive":{  
         "properties":{  
            "date_creation":{  
               "include_in_all":false,
               "store":true,
               "format":"dateOptionalTime",
               "type":"date"
            }
         }
      }
   }

I haven't any ideas of what happens!

[boillodmanuel]

The java heap histogram shows a very high number of InternalDateHistogram$Bucket instances:

 num     #instances         #bytes  class name
----------------------------------------------
   1:      45469412     1818776480  org.elasticsearch.search.aggregations.bucket.histogram.InternalDateHistogram$Bucket

[boillodmanuel]

Without using "min_doc_count" attribute, the query ends normally.

"date_histogram": {
        "field": "date_creation",
        "interval": "month",
        "min_doc_count": 0,
        "time_zone": 1
      }

does not work, but

"date_histogram": {
        "field": "date_creation",
        "interval": "month",
        "time_zone": 1
      }

works fine

[jpountz]

Thanks for the report, this looks like an infinite loop in the reduce logic. I will look into it...

[annirvine]

Do you know if this was a bug in 1.1 also and, if so, if it has been fixed there as well?

[wojcikstefan]

Hi there, I encountered the same issue in ES 1.1.2.

[wojcikstefan]

@jpountz, are you planning to include this fix in the 1.2 branch as well?