Select a category on the left, to get your answers quickly
Creating a new Opensolr Index, is a very simple process.
You can do it either by using the Opensolr Control Panel, or, the Opensolr Automation REST API.
To create a new index, using the Opensolr Control panel you would simply follow the steps below.
In this example, we are creating a new index in US-EAST, Solr Version 7:
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.
In order to perform AJAX HTTP Authenticated requests, you will have to submit a support ticket, and let us know what are the origins where you are making your requests from, so that we can whitelist those, in our cloud infrastructure settings.
You will also have to indicate your index/cluster name, and account registration email address.
Some issues to be mindful about.
Drupal, has changed the way it works, and now, for path, it only requires you to have a SLASH.
Basically, what we call Path (/solr/index_name), in Opensolr, it should be / for your Drupal setup.
And what Drupal calls SolrCore, should be the Name of your Opensolr Index.
Also, if you use Opensolr in SolrCloud mode, please note that the solr server path is /solrcloud instead of /solr. (i.e.: https://server.opensolr.com/solrcloud/index_name/select?...)
So, unless Drupal has decided to hard-code the /solr part of the connection URL, you should be able to use your Opensolr SolrCloud Index, and set your path, in Drupal as /solrcloud, instead of / (slash).
Ultimately, we will help you upload your config files, regardless of the Solr Version you decide to use, as usual, we'll do this for free, and, instantly, during our office hours.
You might also want to watch the clip about all external integration issues.
It is a common misconception, that, if your Drupal module, or any other Solr plugin, requires, say, Solr Version 6.4.x, and Opensolr only provides Solr version 6.1.x, you can't use it with Opensolr.
With small modifications to your Solr config files, we can make your config files work on any of our Solr versions, without any impact on your Solr integration, or functionality overall.
Of course, migrating from one major Solr Version to another, isn't that straight forward, but, we can even, do that.
However, I can't stress enough that, migration between any Solr minor Versions is not only possible, it's even recommended, since we'll do it all for you, if you want to save time, and money, since, of course, Opensolr also offers FREE membership now.
It has also been a common misconception, that, your Opensolr connection URL returns 404 NOT FOUND, and therefore, it can not be used, and something must be broken.
In your Opensolr Control Panel, you will see your connection url as something like the following:
https://useast612.solrcluster.com/solr/opensolr/
Now, that URL, will always return an HTTP STATUS 404 NOT FOUND.
Ironically, that means everything is OK.
Your application will use that, as a base connection URL, and append other Solr Request Handlers to it, as you can see in this example:
https://useast612.solrcluster.com/solr/opensolr/select?q=*:*&wt=json&indent=true&start=0&rows=50&fl=title,description&fq=+content_type_text:(html)
We have added the /select Request Handler, and that very same connection URL is now responding with a full Solr json format response.
It's an OpenSolr Miracle!
In case your Tika Extractor throws errors in your Drupal or other application, here's what you can try:
<requestHandler name="/extract/tika" class="org.apache.solr.handler.extraction.ExtractingRequestHandler" startup="lazy">
<lst name="defaults">
</lst>
<!-- This path only extracts - never updates -->
<lst name="invariants">
<bool name="extractOnly">true</bool>
</lst>
</requestHandler>
In this clip we will talk about some of the most common drupal configuration issues, based on the solr configuration files provided by the Drupal search api module.
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.
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.
Solr works with a set of multiple configuration files.
Each Solr configuration file, has it's own purpose.
Therefore, in some cases, some publishers (CMS systems, etc), will chose to create their own structure for such Solr configuration files, such as, it is the case with Drupal, and maybe WordPress (WPSOLR), and others.
When uploading your solr configuration files, using your Opensolr Index Control Panel, it is, therefore, important to upload your files in a specific order:
So, basically, you should simply create those 3 archives and upload them separately, in this exact order, and then everything should work.
You can, of course automate this, by using the Automation REST API to upload your config files.
ICU library erorrs
While uploading, or saving your config files, via the Opensolr editor, you might probably come across an error that reads something like this:
Error loading class 'solr.ICUCollationField'
The problem is that we will have to enable that library on our end.
Therefore, if you encounter this, please Contact Us in order to request the ICU library to be activated for your server.
If unsure what type of error you're getting, you can always see your Error Logs once you've uploaded your config files, by Clicking your Index Name->Tools->Error Logs
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>
YES, however, it's only active in some servers right now.
Please ask us to install that, or any other plugin solr library, by following the guide here, and we'll be happy to set it up for you.
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.
To move from using the managed-schema to schema.xml, simply follow the steps below:
In your solrconfig.xml file, look for the schemaFactory definition.If you have one, remove it and add this instead:
<schemaFactory class="ClassicIndexSchemaFactory"/>
If you don't have it just add the above snippet somewhere above the requestHandlers definitions.
To move from using the classic schema.xml in your opensolr index, to the managed-schema simply follow the steps below:
In your solrconfig.xml, look for a SchemaFactory definition, and replace it with this snippet:
<schemaFactory class="ManagedIndexSchemaFactory"> <bool name="mutable">true</bool> <str name="managedSchemaResourceName">managed-schema</str> </schemaFactory>
If you don't have any schemaFactory definition, just paste the above snippet to your solrconfig.xml file, just about any requestHandler definition.
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.
Please go to https://opensolr.com/pricing and make sure you select the analytics option from the extra features tab, when you upgrade your account.
If you can see analytics but no data, make sure your solr queries are correctly formated in the form:
https://server.opensolr.com/solr/index_name/select?q=your_query&other_params...
So, the search query must be clearly visible in the q parameter in order for it to show in analytics.
Here are a few ways to save your Monthy alloted Bandwidth:
There are a couple things you might be able to do to trade performance for index size. For example, an integer (int) field uses less space than a trie integer (tint), but range queries will be slower when using an int.
To make major reductions in your index, you will almost certainly need to look more closely at the fields you are using.