# A previously working ES 9.0 query may sometimes produce a ReduceSearchPhaseException after adding new data **URL:** \ **Category:** Elasticsearch\ **Created:** [July 29, 2010, 8:52pm UTC](https://discuss.elastic.co/t/a-previously-working-es-9-0-query-may-sometimes-produce-a-reducesearchphaseexception-after-adding-new-data/3173 "2010-07-29T20:52:16Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Jack\_Key](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/jack_key/32/3321_2.png) [@Jack\_Key](https://discuss.elastic.co/u/Jack_Key)\ **Post date:** [July 29, 2010, 8:52pm UTC](https://discuss.elastic.co/t/a-previously-working-es-9-0-query-may-sometimes-produce-a-reducesearchphaseexception-after-adding-new-data/3173/1 "2010-07-29T20:52:16Z")
Has anyone else noticed an occasional ReduceSearchPhaseException when querying stored data? Specifically, my query on user-defined stored fields works fine at first, but tends to break after data is inserted. This is puzzling because nothing is logged by elasticsearch concerning any sort of error during the data upload or the queries themselves. Could the data upload invalidate an existing, previously working query? The error is difficult to reproduce consistently, because it seems to break arbitrarily.More details are below: I uploaded via REST into an ES 9.0 cluster (deployed on EC2 with ec2\_discovery and s3\_gateway). After PUTting a mapping for my type "biocompare/halcyon" and inserting 3 records, I was able to execute the following search from a terminal successfully, producing good results: curl -XPUT cloud:9200/biocompare/exampletype/\_mapping -d ' { "exampletype" : { "properties" : { "item\_name" : { "type" : "multi\_field", "fields" : { "default" : { "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, "price" : { "type" : "multi\_field", "fields" : { "default" : { "type" : "float", "store" : "no", "index" : "analyzed" }, "facet" : { "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, "Description" : { "type" : "multi\_field", "fields" : { "default" : { "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": "string", "store" : "yes", "index" : "not\_analyzed" } } } ``` } ``` } } ' \ $ curl -XPOST cloud:9200/biocompare/exampletype/\_search -d ' { "from" : 0, "size" : 1, "fields" : ["\_id","price.facet"], "sort" : { "Description.facet" : { } }, "query" : { "match\_all" : { } }, "facets" : { "vendor" : { "terms" : { "field" : "price.facet", "size" : 100, "analyzer" : "none" }, "global" : false } } } ' {"\_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":1,"max\_score":null,"hits":[{"\_index":"biocompare","\_type":"exampletype","\_id":"657","\_score":null}]},"facets":{"vendor":{"\_type":"terms","\_field":"price.facet","terms":[]}}}}} However, after inserting just a few more records, the same query produces a ReduceSearchPhraseException, which is a bad result: {"error":"ReduceSearchPhaseException[Failed to execute phase [query], [reduce] ]; nested: "} How can this be? The same query against the same node seems to be broken after inserting additional records! Is it possible to break the query just by adding new records to the data store? Although each new record is acknowledged as "ok" in the JSON response, I discover that at runtime that queries using "sort" and/or "fields" over user-mapped stored fields will fail. This may happen after an insert (the 1st or 3001st -- it is not consistent). Using the same script to insert the data, in the same order, I get this failure at different points. The logs, which have been turned on for all evens I know about (action:DEBUG, gateway:DEBUG, index.shard.recovery:DEBUG) aren't producing anything for this error. However, using the _default_ stored fields (e.g. "\_id", and "\_source") are still fine and still continue to return good results. Does this look familiar to anyone? Also, please let me know and I will quickly provide any additional info you might need on the environment, logs, data uploaded, etc. to help understand the nature of my concern. Regards, Jack Key ---
**Author:** ![kimchy](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kimchy/32/44952_2.png) [@kimchy](https://discuss.elastic.co/u/kimchy)\ **Post date:** [July 29, 2010, 9:51pm UTC](https://discuss.elastic.co/t/a-previously-working-es-9-0-query-may-sometimes-produce-a-reducesearchphaseexception-after-adding-new-data/3173/2 "2010-07-29T21:51:59Z")
Answered on the other thread. Damn google groups with its spam filter... On Thu, Jul 29, 2010 at 11:52 PM, Jack Key [joeandrewkey@gmail.com](mailto:joeandrewkey@gmail.com) wrote: > Has anyone else noticed an occasional ReduceSearchPhaseException when > querying stored data? > Specifically, my query on user-defined stored fields works fine at first, > but tends to break after data is inserted. > This is puzzling because nothing is logged by elasticsearch concerning any > sort of error during the data upload or the queries themselves. Could the > data upload invalidate an existing, previously working query? The error is > difficult to reproduce consistently, because it seems to break > arbitrarily.More details are below: > > I uploaded via REST into an ES 9.0 cluster (deployed on EC2 with > ec2\_discovery and s3\_gateway). > > After PUTting a mapping for my type "biocompare/halcyon" and inserting 3 > records, I was able to execute the following search from a terminal > successfully, producing good results: > > curl -XPUT cloud:9200/biocompare/halcyon/\_mapping -d ' { "halcyon" : { "properties" : { "item\_name" : { "type" : "multi\_field", "fields" : { "default" : { "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "vendor" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "modified" : { "omit\_term\_freq\_and\_positions" : true, "index\_name" : > "modified", "index" : "not\_analyzed", "omit\_norms" : true, "store" : "no", > "boost" : 1.0, "format" : "dateOptionalTime", "precision\_step" : 4, > "term\_vector" : "no", "type" : "date" }, > > "price" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "float", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Antigen" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Antigen Species" : { "type" : "multi\_field", "fields" : { "default" : { > "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { > "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Antigen Synonyms" : { "type" : "multi\_field", "fields" : { "default" : { > "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { > "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Catalog Number" : { "type" : "multi\_field", "fields" : { "default" : { > "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { > "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Concentration" : { "type" : "multi\_field", "fields" : { "default" : { > "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { > "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Conjugate" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Description" : { "type" : "multi\_field", "fields" : { "default" : { "type" > : "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Form" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > "Host Species" : { "type" : "multi\_field", "fields" > : { "default" : { > "type" : "string", "store" : "no", "index" : "analyzed" }, "facet" : { > "type": "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Immunogen" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Isotype" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Quantity" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Reactivity" : { "type" : "multi\_field", "fields" : { "default" : { "type" > : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "References" : { "type" : "multi\_field", "fields" : { "default" : { "type" > : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } }, > > "Type" : { "type" : "multi\_field", "fields" : { "default" : { "type" : > "string", "store" : "no", "index" : "analyzed" }, "facet" : { "type": > "string", "store" : "yes", "index" : "not\_analyzed" } } } > > ``` > } > } > > ``` > > } > ' > \ > > $ curl -XPOST cloud:9200/biocompare/halcyon/\_search -d ' { "from" : 0, "size" : 1, "sort" : ["Description.facet"], "query" : { "match\_all" : { } }} ' > > {"\_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":3,"max\_score":null,"hits":[{"\_index":"biocompare","\_type":"halcyon","\_id":"50682","\_score":null,"fields":{"item\_name.facet":"Goat > Anti-Rabbit IgG, Horseradish Peroxidase Conjugated"}}]}} > \ > > However, after inserting just a few more records, the same query produces a > ReduceSearchPhraseException, which is a bad result: > > {"error":"ReduceSearchPhaseException[Failed to execute phase [query], [reduce] ]; nested: "} > > How can this be? The same query against the same node seems to be broken > after inserting additional records! > Is it possible to break the query just by adding new records to the data > store? > > Although each new record is acknowledged as "ok" in the JSON response, I > discover that at runtime that queries using "sort" and/or "fields" over > user-mapped stored fields will fail. This may happen after an insert (the > 1st or 3001st -- it is not consistent). Using the same script to insert > the > data, in the same order, I get this failure at different points. The logs, > which have been turned on for all evens I know about (action:DEBUG, > gateway:DEBUG, index.shard.recovery:DEBUG) aren't producing anything for > this error. > > However, using the _default_ stored fields (e.g. "\_id", and "\_source") are > still fine and still continue to return good results. > > Does this look familiar to anyone? Also, please let me know and I will > quickly provide any additional info you might need on the environment, > logs, > data uploaded, etc. to help understand the nature of my concern. > > Regards, Jack Key > > -- > View this message in context: > [http://elasticsearch-users.115913.n3.nabble.com/A-previously-working-ES-9-0-query-may-sometimes-produce-a-ReduceSearchPhaseException-after-adding-nea-tp1004896p1004896.html](http://elasticsearch-users.115913.n3.nabble.com/A-previously-working-ES-9-0-query-may-sometimes-produce-a-ReduceSearchPhaseException-after-adding-nea-tp1004896p1004896.html) > Sent from the Elasticsearch Users mailing list archive at [Nabble.com](http://Nabble.com). ---
**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\ **Post date:** [July 6, 2017, 4:21am UTC](https://discuss.elastic.co/t/a-previously-working-es-9-0-query-may-sometimes-produce-a-reducesearchphaseexception-after-adding-new-data/3173/3 "2017-07-06T04:21:24Z")