This page describes the known issues with Acquia Search.
If you select a Solr 9 configset for an Acquia Search index that is not upgraded to Solr 9, the system returns a 409 Conflict error. If you switch to a Solr 8 configset after attempting to set Solr 9, the system returns the same error. The system does not update the configset when you select Solr 9 for an index that is not migrated, so the update remains incomplete. This incomplete update causes a conflict when you switch back to Solr 8.
Workaround: Select a Solr 7 configset for the affected index. Once the configset is successfully applied, switch back to the Solr 8 configset.
In Solr versions before Solr 9, the highlighter default was original. Starting in Solr 9, the default for hl.method is unified.
Workaround:
Option 1: Update your schema (for example, the schema_extra_fields.xml file) and add termOffsets="true" and termPositions="true" to the dynamic fields in question. Then reindex your content.
Option 2 (simpler, recommended): Add or update the hl.method=original block in the solrconfig.xml file. This block must appear at the top level, as a sibling of <searchComponent>.
Cloud Platform <requestHandler name="/select" class="solr.SearchHandler">
<lst name="defaults">
<str name="hl.method">original</str>
</lst>
</requestHandler>If your deployed configsets contain the field, <field name="_root_" type="string" indexed="true" stored="false"/>, after you upgrade from Solr 7 to Solr 8, a duplicate document issue occurs while indexing. When modifying Drupal content, the system creates a new Solr document and does not update the existing document. For more information about this known issue, see SOLR-15540.
To resolve this issue, Acquia:
field name="_root_ from:For more information, see Acquia Search - November 29, 2023.
Workaround:
If you implemented custom configsets, you must remove the field, _root_ as follows:
<field name="_root_" type="string" indexed="true" stored="false"/> line from existing configsets.The _root_ field is required for nested Solr documents. If the use case requires nested Solr documents, you can re-add this field in a custom configset.
For more information, see Issues with large attachments and Solr search in the Acquia Support Knowledge Base.
Acquia Search is hosted within Acquia’s shared virtual private cloud (VPC). Although you can access Acquia Search from your Shield applications, the Acquia Search servers are located outside of your Shield dedicated section. Due to the Acquia Search servers’ location, Shield does not protect your search index. For more information about how Acquia uses VPCs, see Virtual Private Cloud.
Advanced search functionalities, such as Acquia internal backups and select all queries, may fail if the dynamic field sort_X3b_* has class type defined as solr.ICUCollationField, and contains unicode characters from Eastern European languages. This will not affect regular indexing and search operations. For more information, see the Solr ticket.
The FreeTextLookupFactory suggester factory class has a known issue wherein the suggester dictionary is not built in all replicas. Therefore, Acquia recommends you to not use the FreeTextLookUpFactory class.
For more information about the Workbench Moderation module, see its project page on Drupal.org.
For more information about this issue, see Better memory usage on indexing on Drupal.org.
The Search API module provides fewer configuration options than ApacheSolr integration in Drupal 7.
The Search API module can’t display result snippets—the full node output displays as the search result.
Workaround: Create a Search result view mode to output something smaller than the full node. To add the workaround, complete the following steps:
200 to trim the body field to 200 characters.You have now configured the Body field to display trimmed output as the search result.
For more information about this issue, see Views problems with non-SQL query plugins on Drupal.org.
Views exposed filters, such as search results and blocks with facets, must not have caching enabled alongside AJAX. For more information, see Ajax facet block seems to lose views context on Drupal.org.
Acquia Search indexes content types, when that is not the intended behavior.
Workaround: Add a content type filter to an Acquia Search view.
Upgrading the search_api_solr module from version 4.2.x to 4.3.x results in reindexing failure with the following
error:cannot change field "solr_field_name_here" from index options=DOCS_AND_FREQS_AND_POSITIONS to inconsistent index options=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS, message: Solr HTTP error: Bad Request (400)
To successfully perform the upgrade:
By default, Acquia Search stores configuration in the database. When the production database is pulled into a development environment such as Acquia Cloud IDE or local environment, the Solr core/server, site ID (site_hash), and other details get copied over. As a result, the development and the production environments end up sharing the same Solr index. This causes numerous issues including duplicate results, results from the wrong site, and deletion of all content in the production environment’s Solr index.
Workaround: Set the index status to Read only on all development environments.
Option 1 (works for local development environments and Cloud IDEs): In sites/default/settings.local.php, add the following code:
// Check if Acquia environment variable is not set or equals 'ide'.
if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] === 'ide') {
// If there's no 'AH_SITE_ENVIRONMENT' or we are on an Acquia Cloud IDE,
// set Acquia Search to read-only mode.
$settings['acquia_search']['read_only'] = TRUE;
}The "Lock held by this virtual machine" error occurs in Solr when the following actions take place simultaneously:
<str name="indexPath">./SUGGESTERS_NAME</str>en suggester:<str name="indexPath">./en</str> and <str name="indexPath">./und</str>. <lst name="suggester">
<str name="name">en</str>
<str name="lookupImpl">AnalyzingInfixLookupFactory</str>
<str name="dictionaryImpl">DocumentDictionaryFactory</str>
<str name="field">twm_suggest</str>
<str name="suggestAnalyzerFieldType">text_en</str>
<str name="contextField">sm_context_tags</str>
<str name="buildOnCommit">true</str>
<str name="buildOnStartup">false</str>
<str name="indexPath">./en</str>
</lst>If this content did not answer your questions, try searching or contacting our support team for further assistance.
This page describes the known issues with Acquia Search.
If you select a Solr 9 configset for an Acquia Search index that is not upgraded to Solr 9, the system returns a 409 Conflict error. If you switch to a Solr 8 configset after attempting to set Solr 9, the system returns the same error. The system does not update the configset when you select Solr 9 for an index that is not migrated, so the update remains incomplete. This incomplete update causes a conflict when you switch back to Solr 8.
Workaround: Select a Solr 7 configset for the affected index. Once the configset is successfully applied, switch back to the Solr 8 configset.
In Solr versions before Solr 9, the highlighter default was original. Starting in Solr 9, the default for hl.method is unified.
Workaround:
Option 1: Update your schema (for example, the schema_extra_fields.xml file) and add termOffsets="true" and termPositions="true" to the dynamic fields in question. Then reindex your content.
Option 2 (simpler, recommended): Add or update the hl.method=original block in the solrconfig.xml file. This block must appear at the top level, as a sibling of <searchComponent>.
<requestHandler name="/select" class="solr.SearchHandler">
<lst name="defaults">
<str name="hl.method">original</str>
</lst>
</requestHandler>If your deployed configsets contain the field, <field name="_root_" type="string" indexed="true" stored="false"/>, after you upgrade from Solr 7 to Solr 8, a duplicate document issue occurs while indexing. When modifying Drupal content, the system creates a new Solr document and does not update the existing document. For more information about this known issue, see SOLR-15540.
To resolve this issue, Acquia:
field name="_root_ from:For more information, see Acquia Search - November 29, 2023.
Workaround:
If you implemented custom configsets, you must remove the field, _root_ as follows:
<field name="_root_" type="string" indexed="true" stored="false"/> line from existing configsets.The _root_ field is required for nested Solr documents. If the use case requires nested Solr documents, you can re-add this field in a custom configset.
For more information, see Issues with large attachments and Solr search in the Acquia Support Knowledge Base.
Acquia Search is hosted within Acquia’s shared virtual private cloud (VPC). Although you can access Acquia Search from your Shield applications, the Acquia Search servers are located outside of your Shield dedicated section. Due to the Acquia Search servers’ location, Shield does not protect your search index. For more information about how Acquia uses VPCs, see Virtual Private Cloud.
Advanced search functionalities, such as Acquia internal backups and select all queries, may fail if the dynamic field sort_X3b_* has class type defined as solr.ICUCollationField, and contains unicode characters from Eastern European languages. This will not affect regular indexing and search operations. For more information, see the Solr ticket.
The FreeTextLookupFactory suggester factory class has a known issue wherein the suggester dictionary is not built in all replicas. Therefore, Acquia recommends you to not use the FreeTextLookUpFactory class.
For more information about the Workbench Moderation module, see its project page on Drupal.org.
For more information about this issue, see Better memory usage on indexing on Drupal.org.
The Search API module provides fewer configuration options than ApacheSolr integration in Drupal 7.
The Search API module can’t display result snippets—the full node output displays as the search result.
Workaround: Create a Search result view mode to output something smaller than the full node. To add the workaround, complete the following steps:
200 to trim the body field to 200 characters.You have now configured the Body field to display trimmed output as the search result.
For more information about this issue, see Views problems with non-SQL query plugins on Drupal.org.
Views exposed filters, such as search results and blocks with facets, must not have caching enabled alongside AJAX. For more information, see Ajax facet block seems to lose views context on Drupal.org.
Acquia Search indexes content types, when that is not the intended behavior.
Workaround: Add a content type filter to an Acquia Search view.
Upgrading the search_api_solr module from version 4.2.x to 4.3.x results in reindexing failure with the following
error:cannot change field "solr_field_name_here" from index options=DOCS_AND_FREQS_AND_POSITIONS to inconsistent index options=DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS, message: Solr HTTP error: Bad Request (400)
To successfully perform the upgrade:
By default, Acquia Search stores configuration in the database. When the production database is pulled into a development environment such as Acquia Cloud IDE or local environment, the Solr core/server, site ID (site_hash), and other details get copied over. As a result, the development and the production environments end up sharing the same Solr index. This causes numerous issues including duplicate results, results from the wrong site, and deletion of all content in the production environment’s Solr index.
Workaround: Set the index status to Read only on all development environments.
Option 1 (works for local development environments and Cloud IDEs): In sites/default/settings.local.php, add the following code:
// Check if Acquia environment variable is not set or equals 'ide'.
if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] === 'ide') {
// If there's no 'AH_SITE_ENVIRONMENT' or we are on an Acquia Cloud IDE,
// set Acquia Search to read-only mode.
$settings['acquia_search']['read_only'] = TRUE;
}The "Lock held by this virtual machine" error occurs in Solr when the following actions take place simultaneously:
<str name="indexPath">./SUGGESTERS_NAME</str>en suggester:<str name="indexPath">./en</str> and <str name="indexPath">./und</str>. <lst name="suggester">
<str name="name">en</str>
<str name="lookupImpl">AnalyzingInfixLookupFactory</str>
<str name="dictionaryImpl">DocumentDictionaryFactory</str>
<str name="field">twm_suggest</str>
<str name="suggestAnalyzerFieldType">text_en</str>
<str name="contextField">sm_context_tags</str>
<str name="buildOnCommit">true</str>
<str name="buildOnStartup">false</str>
<str name="indexPath">./en</str>
</lst>If this content did not answer your questions, try searching or contacting our support team for further assistance.