I would also add that dealing with Java versions has always been a pain until you get used to the whole "JAVA HOME" thing, but that this isn't anything to do with SOLR per se - it's just part and parcel of dealing with open source software that uses Java...
Big changes between major versions of any software are common - there is some documentation here that may help... https://cwiki.apache.org/confluence/display/solr/Major+Changes+from+Solr+5+to+Solr+6 It was reading this that made me decide to try "upgrade by replace" to avoid the whole "update" issue entirely - although I also had to upgrade Java on my VMs... On Mon, 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.el >> 6_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 > > >
