Documentation

If Solr is throwing the following error:

java.lang.IllegalArgumentException: cannot change DocValues type from <type> to <other_type> for field <fieldName>

The Solr Schema explains DocValues in this way:

DocValues is recommended (required, if you are using *Point fields) for faceting, grouping, sorting and function queries. DocValues will make the index faster to load, more NRT-friendly and more memory-efficient. [DocValues are] currently only supported by StrField, UUIDField, all *PointFields, and depending on the field type, they might require the field to be single-valued, be required or have a default value.

DocValues is set in many schema fields similar to this one:

<field name="date" type="pdate" docValues="true" indexed="true" stored="true" multiValued="false" /> 

DocValues are only available for specific field types. The types chosen determine the underlying Lucene docValue type that will be used. The available Solr field types are:

StrField and UUIDField.

If the field is single-valued (i.e., multi-valued is false), Lucene will use the SORTED type.
If the field is multi-valued, Lucene will use the SORTED_SET type.
Any Trie* numeric fields, date fields and EnumField.
If the field is single-valued (i.e., multi-valued is false), Lucene will use the NUMERIC type.
If the field is multi-valued, Lucene will use the SORTED_SET type.
Boolean fields
Int|Long|Float|Double|Date PointField
If the field is single-valued (i.e., multi-valued is false), Lucene will use the NUMERIC type.
If the field is multi-valued, Lucene will use the SORTED_NUMERIC type.
From the above, you can see that Solr’s complaint that it “cannot change a DocValues type” implies that someone has changed the definition of the named field, probably by altering the DocValues setting or by changing the multivalue setting.

Possible Solutions:

A field change requires you to reset your index (remove all index data) from your Opensolr Index Control Panel and Re-index the data. Otherwise, the conflict between schema and index will cause many downstream error messages.

If that fails, try creating a new index, and Re-index the data in the new index. (This requires setting up your Drupal Server connection information).

Solr indexing error:

ERROR (qtp123456-78) <replica> o.a.s.h.RequestHandlerBase org.apache.solr.common.SolrException: Invalid Number: <bad value> for field <numeric field>

This is one of many Indexing Errors that we encounter. It means that your application sometimes issues a non-numeric value to a numeric field. This results in the document being dropped from the index. The error message usually identifies both the broken value and the field.

This could indicate a schema field-definition error, but the examples we see commonly involve legacy data or issues in the code that generates the value.

You should try to make sure that the data you send to Solr matches the field Types defined in your Solr schema.xml file.

If all fails, please Contact Support.

UPDATE - July, 09 2024:

This is now being set in your solr.xml file that resides in your solr home directory (where your cores / collections are):

<solr>
 <int name="maxBooleanClauses">90589</int>
 <shardHandlerFactory name="shardHandlerFactory"
 class="HttpShardHandlerFactory">
 <int name="socketTimeout">${socketTimeout:600000}</int>
 <int name="connTimeout">${connTimeout:60000}</int>
 </shardHandlerFactory>
</solr>

If you get the Solr error: "too many boolean clauses", please try to check your synonyms.txt, stopwords.txt or protwords.txt, and try to make those files smaller.

In other words, Solr is trying to apply boolean clauses for each one of those words that are found in any of those files, depending on your schema.xml configuration.

A quick fix, is to remove some of the synonyms from synonyms.txt or other words from the other txt files shown here, and/or you can also take a look at your schema.xml and make sure that your synonyms, stopwords and protwords are configured properly in the chain of tokenizers and filters for your fieldType definitions.

Also, try not to apply synonyms.txt at indexing time, as that replaces many of the original words with their synonyms, considerably increasing the size of your index, and also make search far less relevant in some cases.

Here's an example setup for the synonyms.txt usage, in a text_general field, that we use for our Web Crawler Site Search solution:

<fieldType name="text_general" class="solr.TextField" positionIncrementGap="100">
 <analyzer type="index">
 <charFilter class="solr.HTMLStripCharFilterFactory"/>
 <tokenizer class="solr.WhitespaceTokenizerFactory"/>
 <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/>
 <filter class="solr.WordDelimiterGraphFilterFactory" catenateNumbers="1" generateNumberParts="1" protected="protwords.txt" splitOnCaseChange="0" generateWordParts="1" preserveOriginal="1" catenateAll="0" catenateWords="1"/>
 <filter class="solr.LengthFilterFactory" min="2" max="100"/>
 <filter class="solr.LowerCaseFilterFactory"/>
 <filter class="solr.SnowballPorterFilterFactory" protected="protwords.txt" language="English"/>
 <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
 </analyzer>
 <analyzer type="query">
 <charFilter class="solr.HTMLStripCharFilterFactory"/>
 <tokenizer class="solr.WhitespaceTokenizerFactory"/>
 <filter class="solr.SynonymGraphFilterFactory" ignoreCase="true" synonyms="synonyms.txt" expand="true"/>
 <filter class="solr.StopFilterFactory" ignoreCase="true" words="stopwords.txt"/>
 <filter class="solr.WordDelimiterGraphFilterFactory" catenateNumbers="0" generateNumberParts="1" protected="protwords.txt" splitOnCaseChange="0" generateWordParts="1" preserveOriginal="1" catenateAll="0" catenateWords="0"/>
 <filter class="solr.LengthFilterFactory" min="2" max="100"/>
 <filter class="solr.LowerCaseFilterFactory"/>
 <filter class="solr.SnowballPorterFilterFactory" protected="protwords.txt" language="English"/>
 <filter class="solr.RemoveDuplicatesTokenFilterFactory"/>
 </analyzer>
</fieldType>

You can learn more here.

For any questions that look like those below:

Why am I not getting results for query A, in AJAX, but I am getting results for query A, without AJAX?
Why am I not getting results for query A?
Why am I not getting results for query B?

For all of the above questions, you should refer to the online Solr documentation, or, the Drupal Community (if using Drupal).

Opensolr, provides the Solr as a Service platform.
Solr search results are not under the responsability of Opensolr, but rather, the way queries will work, depends solely on your Solr implementation, or the implementation of the CMS system you are using.

Please be advised that, your Opensolr Index may fail to reload, when using AnalyzingInfixSuggester

It turns out, that Drupal, is exporting the Solr Configuration zip archive erroneously.

Basically, you will need to manually edit solrconfig_extra.xml, in order to explicitly specify a separate folder for each suggester dictionary.

You can click here to learn more, from the Bug reported to the Drupal Community.

UPDATE: As of Feb 08 2023, the new Opensolr Config Files Uploader, should take care of these dependencies automatically, so the steps below should not be necessary.

However, if you still run into issues, you can try the steps below:

There is often the case (as it is with drupal), that your config files will contain files like schema_extra.xml, or solrconfig_extra.xml

In this case, your main schema.xml and solrconfig.xml will contain references to various fields and types that are defined in those extra files.

Therefore, you need to split your config files archive into multiple archives, and upload them as follows:

- First upload the extra files (zip up the schema_extra.xml and other *_extra.xml files and upload that zip first)
- Second upload the main schema.xml file, along with all other resource files, such as stopwords.txt, synonyms.txt, etc.
- Third, upload a zip archive that contains solrconfig.xml alone.

If you get the error:

Undefined field _text_

Please make sure to open up solrconfig.xml in your Opensolr Control Panel Admin UI and remove the reference to the _text_ field under the /update initParams:

<initparams path="/update/**,/query,/select,/tvrh,/elevate,/spell,/browse">
 <lst name="defaults"></lst>
 <str name="df">_text_</str>
</initparams>

Sometimes, in the shared opensolr cloud, the data folder may get corrupted, so it can't be read from or written into.
One easy fix for this, is to simply remove your index, and then just create another one, preferably under another name.

If that doesn't work, please contact us, and we'll be happy to fix it up for you.

Also, keep in mind, that there may be more reasons, so please make sure to check your error log, by clicking the Error Log button inside your opensolr index control panel, and keep refreshing that page to make sure the errors you'll see are accurate.

If you do see errors in there, please email them to us, at support@opensolr.com and we'll fix it for you.

If you usually get an error, such as: Unknown field... Or Missing field, and your schema.xml already contains those fields, make sure you disable the Schemaless mode in solrconfig.xml

Just head on to the Config Files Editor in your opensolr index control panel, and locate a snippet that looks like this:

class="ManagedIndexSchemaFactory"

According to the solr documentation, you can disable the ManagedIndexSchemaFactory as per the instructions below:

To disable dynamic schema REST APIs, use the following for :

<schemaFactory class="ClassicIndexSchemaFactory"/>

Also do not forget to remove the entire snippet regarding the ManagedIndexSchemaFactory, so that you won't accidentally use both.

Yes, Opensolr now supports the  JTS Topology Suite, by default, which does not come bundled with the default Solr distribution.
It should be enabled in most of our servers and datacenters, however, if you feel that doesn't work for your index, please Contact Support and we'll be happy to enable it for you.
No further setup will be required on your part.