On my production server queries can fail if one word changes. This is reliable. Its just the word change that triggers the error, not a fluke of unfortunate timing (i.e. the server is overloaded)
ES 7.8 with php APi 7.7
Error: BadRequest400Exception
Search term: very long search term here and economic
Query sent as (php print_r output btw)
BUT the query string
very long search term here and contains
works fine!
As does
very long search term here and continuity
but NOT
very long search term here and children
Just changing one word causes the fail, continuity OK, children nope. (those pesky kids)
p.s. I have just upgraded the PHP API to 7.11 (the latest) via composer, with no affect on the problem. Nor can I find any such thing as reserved words in Elasticsearch.
can you share the JSON queries you are sending to Elasticsearch plus the JSON responses coming from Elasticsearch - otherwise debugging this will be super hard.
Moving forwards:
Enabling monolog has revealed this error:
field doc of [appeals3] index has exceeded [1000000] - maximum allowed to be analyzed for highlighting.
It appears a few of my documents are much larger than I originally planned for.
Thus am I right in thinking that changing the index from this: "document_content" : { "type" : "text", "analyzer" : "bespoke_snowball" },
to this: "document_content" : { "type" : "text", "term_vector" : "with_positions_offsets", "analyzer" : "bespoke_snowball" },
and rebuilding my index will magically fix the problem and use the fast highlighter instead?
I realise I could just increase the index.highlight.max_analyzed_offset but this would be a "bodgit and run" solution. Adding the term vector appears straight forward.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.