Skip to main content

Global Search reaches maxBooleanClauses limit

Symptoms​

  • Global Search returns no results for long search input, typically around 12 characters or more.
  • Global Search returns no results when users enter several search terms, typically four or more words.
  • Global Search returns no results for complete email addresses, for example t.admin@example.adito.de.

Causes​

The configured Solr maxBooleanClauses limit is usually sufficient for normal Global Search usage. If the limit is reached, the query often expands into too many Boolean clauses because too many fields or field types are involved.

This issue only affects fields that are used in Global Search and have the isGlobalSearchField property enabled.

Common causes are:

  • Too many fields are configured as Global Search fields. The number of Global Search fields is a direct multiplicative factor when Solr calculates the required Boolean clauses.
  • One or more Global Search field types generate many additional terms for a search input. This can happen with phonetic field types and field types that use shingle filters or many synonyms.
  • Email or phone number fields generate many terms for complete addresses, formatted numbers, or long input values.

How to verify​

Check whether the Solr instance is configured with the expected maxBooleanClauses setting. In ADITO 2025 systems, Solr should be started with -Dsolr.max.booleanClauses=200000. You can verify the active Solr startup arguments in the Solr AdminUI dashboard or in the Solr ADITO-Cloud settings.

If the setting is present, inspect the Global Search field configuration:

  • Review all IndexRecordContainer field mappings that have isGlobalSearchField enabled.
  • Count how many fields are included in Global Search for each index group.
  • Check whether internal fields such as IDs, Solr filter fields, record filter fields, or lookup-only fields are included even though users do not need to search them manually.
  • Check whether Global Search fields use PROPER_NAME, ADDRESS, EMAIL, or PHONE_NUMBER.

Use the Solr AdminUI analysis view to inspect how many terms are generated for representative input values. The Index field types reference describes the analyzer behavior of the affected field types.

tip

Test with the same kind of input that users report as failing. Long names, complete email addresses, and formatted phone numbers are useful test values because they expose term expansion more clearly than short single-word queries.

Solutions​

First verify that the Solr instance uses the expected maxBooleanClauses setting. If the setting is missing in an unmanaged system, add the JVM argument to the existing SOLR_OPTS value and restart Solr:

SOLR_OPTS="<existing-options> -Dsolr.max.booleanClauses=200000"

For managed systems, contact the responsible operator if the setting is missing or differs from the expected value.

If the setting is correct, reduce the number of generated Boolean clauses by adjusting the Global Search configuration.

Reduce the number of Global Search fields​

Review all index groups and keep only fields that users must be able to search manually in Global Search. Remove isGlobalSearchField from fields that are only used for technical filtering, record filters, lookup support, or internal identifiers.

Each removed Global Search field reduces the multiplicative factor for maxBooleanClauses and makes searches with more complex field types less likely to reach the limit.

Replace field types that generate many terms​

If the issue persists, review the field types used by Global Search fields:

  • Change Global Search fields using PROPER_NAME or ADDRESS to TEXT_NOSTOPWORDS if phonetic search is not required for these fields.
  • Check Global Search fields using EMAIL or PHONE_NUMBER. These fields can initially be changed to COMMUNICATION for Global Search.

After changing isGlobalSearchField or indexFieldType, deploy the changes and rebuild the complete index or the affected index groups. The updated field configuration only takes effect after the index has been rebuilt.

Search behavior after changing field types​

Changing field types can improve query stability and performance, but it also changes how matching works.

Phonetic field types​

PROPER_NAME and ADDRESS are phonetic field types. They support searches that match terms by pronunciation or linguistic similarity.

Changing these fields to TEXT_NOSTOPWORDS removes that phonetic behavior. Searches become more exact, which can improve precision and performance, but less tolerant of spelling variants.

This trade-off is often acceptable for Global Search because phonetic matching can be imprecise for longer words, can work poorly outside English-oriented soundex behavior, and can produce false positives for numeric input.

Email and phone number field types​

EMAIL and PHONE_NUMBER are specialized field types for their respective input formats.

Changing EMAIL to COMMUNICATION can increase the chance of false-positive matches for non-email input, but email search usually remains usable because COMMUNICATION also handles email-like values.

Changing PHONE_NUMBER to COMMUNICATION has a stronger impact. PHONE_NUMBER is optimized for formatted phone numbers and country-code normalization, for example matching values such as 0871/1234-567, 08711234567, and +498711234567. COMMUNICATION can still match formatted phone numbers, but it does not provide the same country-code normalization and can return more false-positive matches for partial numbers.

Problem isn't solved?​

Other guides for problems with similar symptoms: