Interested for sure Bill Bell Sent from mobile
> On Sep 12, 2016, at 4:05 PM, John Bickerstaff <j...@johnbickerstaff.com> > wrote: > > For what it's worth - I found enough frustration upgrading that I decided > to "upgrade by replacement" > > Now, I suppose if you've got a huge dataset to re-index that could be a > problem, but just in case an option like that helps you, I'll suggest this. > > 1. Install 6.x on a new machine using the "install for production" > instructions > 2. Use the configs from one of the sample projects to create an > appropriately-named collection > 3. Use the ability to "include" your configs into the other configs (they > live in separate files) > I can provide more help here if you're interested > 4. Re-index all your data into the new version of SOLR... > > I have rough, but useable docs on this if you are interested in attempting > this approach. > > On Mon, Sep 12, 2016 at 3:48 PM, Aaron Greenspan < > aaron.greens...@plainsite.org> wrote: > >> 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
