On 8/22/2016 9:18 PM, Stephen Lewis wrote: > Oops, apologies for my confusing grammar and for missing the > attachment. The intro sentence should have read "I have a question > about upgrading a solr cloud cluster in place." I've actually attached > the log below this time.
The mailing list eats most attachments. Sometimes they make it through, usually they don't, and I never can see what causes the difference. Your attachment did not make it through. For us to see it, you will need to to place the log somewhere on the Internet and provide a URL to access it. When you get a message saying that application/octet-stream was expected but text/html is received instead, it usually means what was received from the remote server was an error page, instead of the javabin response that was expected. To see what that error is, you'll need to check the log on the remote server -- in this case, the server with IP address 172.18.6.68. Further down in the thread you did mention a NoSuchMethodError. If that's the error message from 172.18.6.68, then I agree with Erick's assessment. You've probably got multiple versions of Solr jars on your classpath. Best guess is that your bootstrapping step copies the install directory without deleting anything from the target, which would *add* jars to server/solr-webapp/webapp/WEB-INF/lib. The jars in the two versions of Solr do not have the same names -- the full version number is part of the filename. I can anticipate a possible next question: Why did it work when upgrading from 6.0.0 to 6.0.1? The answer: Mixing jars would most likely work with those two versions, because that's a bugfix release, and bugfix releases are usually 100 percent API/ABI compatible with the previous version. Breaks in that compatibility are expected in minor version upgrades on the server side, especially in code relating to SolrCloud. That code is evolving *VERY* rapidly. If you do not see evidence supporting the multiple-jar-version idea, then you may need to provide access to the logfile. We do *try* to ensure API/ABI compatibility on the the *client* side so user programs can update SolrJ to a new minor version without recompiling ... but even that is not guaranteed. Thanks, Shawn
