Hi,
I have been on this list for some time because I know that any time I try to do
anything related to Solr I’m going to have to spend hours on it, wondering why
everything has to be so awful, and I just want somewhere to provide feedback
with the dim hope that the product might improve one day. (So far, for my
purposes, it hasn’t.) Sure enough, I still absolutely hate using Solr, and I
have more feedback.
I started with a confusing error on the web console, which I still can’t figure
out how to password protect without going through an insanely process involving
"ZooKeeper," which I don’t know anything about, or have, to the best of my
knowledge:
Problem accessing /solr/. Reason:
Forbidden
According to logs, this apparently meant that a MySQL query had failed due to a
field name change. Since I would have to change my XML configuration files, I
decided to use the opportunity to upgrade from Solr 5.1.4 to 6.2.0. It broke
everything.
First I was getting errors about "Unsupported major.minor version 52.0", so I
needed to install the Linux x64 JRE 1.8.0, which I managed on CentOS 6 with...
yum install openjdk-1.8.0
...going to Oracle’s web site, downloading the latest JRE 1.8 build, and then
running...
yum localinstall jre-8u101-linux-x64.rpm
So far so good. But I didn’t have JAVA_HOME set properly apparently, so I
needed to do the not-exactly-intuitive…
export
JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.101-3.b13.el6_8.x86_64/jre/
As usual, I manually moved over my mysql-connector-java-5.1.38-bin.jar file
from the dist/ folder in the old version to the new one. Then after stopping
the old process (with kill -9, since there seems to be no graceful way to shut
down Solr—README.txt doesn’t mention bin/solr stop) I moved over my two core
folders from the old server/solr/ folder. I tried to start it up with bin/solr
start, and watched the errors roll in.
There was some kind of problem with StopFilterFactory and the text_general
field type. Thanks to Stack Overflow I was able to determine that the apparent
problem was that there was a parameter, previously fine, which was no longer
fine. So I removed all instances of enablePositionIncrements="true". That
helped, but then I ran into a broader error: "Plugin Initializing failure for
[schema.xml] fieldType". It didn’t say which field type. Buried in the logs I
found a reference in the Java stack trace—which *disappears* (and distorts the
viewing window horribly) after a few seconds when you try to view it in the web
log UI—to the string "units="degrees"". Sure enough, this string appeared in my
schema.xml for a class called "solr.SpatialRecursivePrefixTreeFieldType" that
I’m pretty sure I never use. I removed that parameter, and moved on to the next
set of errors.
Apparently there is some aspect of the Thai text field type that Solr 6.2.0
doesn’t like. So I disabled it. I don’t use Thai text.
Now Solr was complaining about "Error loading class
'solr.admin.AdminHandlers'". So I found the reference to
solr.admin.AdminHandlers in solrconfig.xml for each of my cores and commented
it out. Only then did Solr work again.
This was not a smooth process. It took about two hours. The user interface is
still as buggy as an early alpha of most products, the errors are difficult to
understand when they don’t actually specify what’s wrong (and they almost never
do), and there should have been an automatic process to highlight and fix
problems in old (pre-6) configuration files. Never mind the fact that the
XML-based configuration process is an antiquated nightmare when the rest of the
world has long since moved onto databases.
Maybe this will help someone else out there.
Aaron
PlainSite | http://www.plainsite.org
