Delay automaton creation in BinaryDvConfirmedQuery to avoid OOM on queries against WildCard fields

[iverase]

We have observed some OOM exceptions on queries containing boolean queries with many nested wildcard BinaryDvConfirmedQueries. What is annoying on these situations is that those queries will likely hit the max boolean clauses and never succeed but because we are eagerly creating the automatons when creating the queries, we are exhausting the heap available.

In order to avoid that, this change proposes to delay the creation of the automatons when we create the Weight of the query, giving a change to the max boolean clause to stop the execution of abusive queries.

[elasticsearchmachine]

Pinging @elastic/es-search-relevance (Team:Search Relevance)

[elasticsearchmachine]

Hi @iverase, I've created a changelog YAML for you.

[benwtrent]

This helps us in an extreme edge case for sure. I wonder how much we will gain here though.

Do you know why we don't eagerly check BoolQueryBuilder as well before building the inner queries at all? It seems like we should be checking in our builders directly even before we construct the Lucene queries.

[iverase]

Do you know why we don't eagerly check BoolQueryBuilder as well before building the inner queries at all?

I don't know, we rely on the lucene implementation that does the check after rewrite. IMHO the current implementation is wrong as it happens too late and sometimes double count some queries magically.