I am new to Solr.
I have created two cores from the admin page, let's call them "books" and "libraries", and imported some data there. Everything works without a hitch until I restart the server. When I do so, one of these cores disappears, and the logging screen in the admin page contains:
SEVERE CoreContainer null:java.lang.NoClassDefFoundError: net/arnx/jsonic/JSONException
SEVERE SolrCore REFCOUNT ERROR: unreferenced org.apache.solr.core.SolrCore#454055ac (papers) has a reference count of 1
I was testing my query in the admin interface; when I refreshed it, the "libraries" core was gone, even though I could normally query it just a minute earlier. The contents of solr.xml are intact. Even if I restart Tomcat, it remains gone.
Additionally, I was trying to build a query similar to this: "Find books matching 'war peace' in libraries in Atlanta or New York". So given cores "books" and "libraries", I would issue "books" the following query (which might be wrong, if it is please correct me):
(title:(war peace) blurb:(war peace))
AND _query_:"{!join
fromIndex=libraries from=libraryid to=libraryid
v='city:(new york) city:(atlanta)'}"
When I do so, the query fails with "libraries" core disappears, with the above symptoms. If I re-add it, I can continue working (as long as I don't restart the server or issue another join query).
I am using Solr 4.0; if anyone has a clue what is happening, I would be very grateful. I could not find out anything about the meaning of the error message, so if anyone could suggest where to look for that, or how go about debugging this, it would be really great. I can't even find where the log file itself is located...
I would avoid the Debian package which may be misconfigured and quirky. And it contains (a very early build of?) solr 4.0, which itself may have lingering issues; being the first release in a new major version. The package maintainer may not have incorporated the latest and safest Solr release into his package.
A better way is to download Solr 4.1 yourself and set it up yourself with Tomcat or another servlet container.
In case you are looking to install SOLR 4.0 and configure, you can following the installation procedure from here
Update the solr config for the cores to be persistent.
In your solr.xml, update <solr> or <solr persistent="false"> to <solr persistent="true">
Related
My team is working on a search application for our websites. We are using Collective Solr in Plone to index our intranet and documentation sites. We recently set up shared blob storage on our test instance of the intranet site because Solr was not indexing our PDF files. This appears to be working, however, each time I run the reindexing script (##solr-maintenance/reindex) it stops after about an hour and a half. I know that it is not indexing our entire site as there are numerous pages, files, etc. missing when I run a query in the Solr dashboard.
The warning below is the last thing I see in the Solr log before the script stops. I am very new to Solr so I'm not sure what it indicates. When I run the same script on our documentation site, it completes without error.
2017-04-14 18:05:37.259 WARN (qtp1989972246-970) [ ] o.a.s.h.a.LukeRequestHandler Error getting file length for [segments_284]
java.nio.file.NoSuchFileException: /var/solr/data/uvahealthPlone/data/index/segments_284
I'm hoping someone out there might have more experience with Collective Solr for Plone and could recommend some good resources for debugging this issue. I've done a lot of searching lately but haven't found much useful info.
This was a bug fixed some time ago with https://github.com/collective/collective.solr/pull/122
I've been trying to set up CKAN, however I am facing some problems in SOLR.
Everytime I run CKAN, the SOLR log file registers a new event, and that is:
org.apache.solr.common.SolrException: sort param field can't be found: metadata_modified
I am trying to use CKAN for the first time and I have no experience at all, so I have no idea what that log event means, nor how to fix it.
EDIT:
When I reload the core at SOLR, the following is logged:
The schema has been upgraded to managed, but the non-managed schema schema.xml is still loadable. PLEASE REMOVE THIS FILE.
Could anyone help me?
Many thanks.
Well, turns out the SOLR 6, for some reason, was the problem.
Downgrading to version 5 worked for me.
This sounds like you are not using CKAN's custom Solr schema. Make sure to go over all points in the setup documentation, specially point 2, and to restart jetty afterwards:
sudo service restart jetty
NOTE: I've tried everything in the comments below and everything else I can think of. At this point I have to assume there's a bug of some kind and that a restart will NOT bring SOLR up in cloud mode unless you roll your own init.d stuff.
==================================================
I have 3 SOLR nodes and 3 Zookeeper nodes.
The SOLR Nodes are SOLR 5.4 on Ubuntu 14 and were installed based on the instructions here:
https://cwiki.apache.org/confluence/display/solr/Taking+Solr+to+Production
If I issue this command to start or restart SOLR on the command line, everything looks fine in the SOLR Admin UI and all my nodes are green in the UI
sudo /opt/solr/bin/solr restart -c -z 192.168.56.5,192.168.56.6,192.168.56.7/solr5_4
However, even though I have a ZK_HOST entry in my solr.in.sh I cannot get the nodes to show up in the SOLR Admin console correctly if I try:
service solr restart
Or if I reboot the VM.
My ZK_HOST entry in solr.in.sh looks like this:
ZK_HOST="192.168.56.5,192.168.56.6,192.168.56.7/solr5_4"
I also tried it this way (no quotes, just in case) because that's how it looks on the Apache wiki page I was reading:
ZK_HOST=192.168.56.5,192.168.56.6,192.168.56.7/solr5_4
I always have to run the command line to get the SOLR instances to show up correctly in the Admin UI. It would be preferrable to have this "just happen" when rebooting the VM.
If I run service solr restart on any of them, they show as "down" in the Admin UI and the core I am using disappears from the Admin UI for the one IP address I'm looking at.
Why is this and what settings are required to get SOLR to start on boot into "Cloud Mode" with the correct Zookeeper settings?
Until a recent change, the docs for setting SOLR up for Prod had a slight misdirection. The bottom line here is that /etc/default/solr.in.sh was what controlled the SOLR configs on startup. NOT the one mentioned in the docs (which was somewhere else anyway /opt/solr/bin)
Once I added the ZKHOST setting in /etc/default/solr.in.sh and restarted the service (or rebooted the server) SOLR came up in "Cloud" mode every time.
I setup my solr instance to run the way I wanted. The service was restarted and all my setup was removed and 4 gettingstarted cores were loaded.
Can someone explain why this happened and what I can do to prevent it from happening again. I would like the cores that I built to be persistent.
Thanks for your help
Edit: Looking over :
https://cwiki.apache.org/confluence/display/solr/Moving+to+the+New+solr.xml+Format
I have the solr.xml setup exactly like the example. I have the core.properties files setup properly. I don't see how it is suppose to know to load the core I created.
Edit2: I found this documentation that states any core.properties files in the home folder will be used.
https://cwiki.apache.org/confluence/display/solr/Solr+Cores+and+solr.xml
Assuming Solr 5, it sounds like you run /bin/solr restart and got wrong collections. The reason to that would be that the restart command needs the same parameters as the start command, most importantly your solr home path.
Solr home is what you provided with -s parameter when you started your Solr the last time. If you did it instead by starting from an example, this guide on solr home locations should help.
I have Solr 4.10 and I have collection on it with solorconfig.xml has the value for <luceneMatchVersion> as follows:
<luceneMatchVersion>4.7</luceneMatchVersion>
Is this correct? I saw other examples that has values such as LUCENE_35 What I need to know also, how could I express LUCENE_xx from my current Solr version?
You should use:
<luceneMatchVersion>4.10.4</luceneMatchVersion>
I recommend you to check your current solr version, in my case was 4.10.4.
if you are going to reindex, then both numbers should match. The only reason you might want to have them different, is if you had and index created with say Lucene 4.7, then you would have
<luceneMatchVersion>4.7</luceneMatchVersion>
Then, you upgrade lucene to 4.10.
Now, if among the changes in between 4.7 and 4.10 there are things that work differently regarding analysis (you get the same sentence analysed in both versions and get different output as a result), then, you might want to keep the version number at 4.7, otherwise some queries that contain affected terms might not work (as they were analysed at index time in a different way than at query time). You have to asses how critical that issue might be.
That is why the recommendation is to upgrade, change the setting to the current number, and reindex. This way you are sure to avoid any issue.
If anyone is using Drupal, the Search API Solr (search_api_solr) module has config templates by version in /sites/all/modules/search_api_solr/solr-conf/.
The template README.md states the following:
The solr-conf-templates directory contains config-set templates for
different Solr versions.
These are templates and are not to be used as config-sets!
To get a functional config-set you need to generate it via the Drupal
admin UI or with drush solr-gsc. See README.md in the module
directory for details.
The module's README.md lists these instructions:
Make sure you have Apache Solr started and accessible (i.e. via port 8983). You can start it without having a core configured at
this stage.
Visit Drupal configuration (/admin/config/search/search-api) and create a new Search API Server according to the search_api
documentation using "Solr" as Backend and the connector that
matches your setup. Input the correct core name (which you will
create at step 4, below).
Download the config.zip from the server's details page or by using drush solr-gsc with proper options, for example for a server named
"my_solr_server": drush solr-gsc my_solr_server config.zip 8.4.
Copy the config.zip to the Solr server and extract.
I generated a config file for 8.x, and it uses this:
<luceneMatchVersion>${solr.luceneMatchVersion:LUCENE_80}</luceneMatchVersion>