That's usually an indication that your classpath has old and new jars
in it. When you start Solr,
the directories from which all the jars are listed in the log file. My
guess is that if you examine them
you'll see jar files loaded from both 6.0 and some from 6.1 and you
need to figure out how
that happened and undo it....
Best,
Erick
On Mon, Aug 22, 2016 at 8:31 PM, Stephen Lewis <i...@stephen-lewis.net> wrote:
> In particular, I see this line. Was there perhaps a deprecation of a method
> or something changed about cluster properties?
>
> <head>
> <meta http-equiv=\"Content-Type\" content=\"text/html;charset=utf-8\"/>
> <title>Error 500
> {msg=org.apache.solr.common.cloud.ZkStateReader.getClusterProps()Ljava/util/Map;,trace=java.lang.NoSuchMethodError:
> org.apache.solr.common.cloud.ZkStateReader.getClusterProps()Ljava/util/Map;
>
> On Mon, Aug 22, 2016 at 8:18 PM, Stephen Lewis <i...@stephen-lewis.net>
> 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.
>>
>> Thanks again,
>> Stephen
>>
>> On Mon, Aug 22, 2016 at 7:41 PM, Stephen Lewis <i...@stephen-lewis.net>
>> wrote:
>>
>>> Hello,
>>>
>>> I have a question about updating a solr cloud cluster servers in place. I
>>> have a scripted method for updating a solr cloud in place, which works
>>> consistently to up/down grade between 6.0.0 and 6.0.1 (in our test
>>> environment), but hits an error consistently when going from either to solr
>>> 6.1.0. Each server is hosting a single solr node, and each shard has a
>>> replication factor of 3.
>>>
>>> The way the script works is as follows. For each instance:
>>>
>>> 1. Pull the instance from serving requests and drain.
>>> 2. Delete the replica from the collection (but leave the index and data)
>>> 3. If that node was the leader, force a leader election (solr is not
>>> accepting writes at this time, so this is safe)
>>> 4. Run a bootstrapping script on the remote machine (which installs a
>>> particular solr version, and is otherwise idempotent)
>>> 5. Once the instance is updated and solr is confirmed, add the node as a
>>> replica where it used to be
>>> 6. Wait for recovery
>>> 7. Reserve requests from this node.
>>>
>>> As mentioned, this hasn't shown any problem switching between versions
>>> 6.0.0 and 6.0.1, but when I try to use this to upgrade to solr 6.1.0, the
>>> "ADDREPLICA" command fails as follows:
>>>
>>> "status":500,"QTime":65},"failure":{"172.18.6.68:8983_solr":"org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:Error
>>> from server at http://172.18.6.68:8983/solr: Expected mime type
>>> application/octet-stream but got text/html
>>>
>>> I've included the full log below as an attachment. The exact request
>>> being served is the following:
>>>
>>> http://52.91.138.30:8983/solr/admin/collections?wt=json&acti
>>> on=ADDREPLICA&collection=panopto&shard=shard2&node=172.18.6.68:8983_solr
>>>
>>> I didn't see any special actions which needed to be taken when upgrading
>>> to 6.1.0. Is there perhaps something wrong in my upgrade methodology or
>>> anything else you're aware of which may be related?
>>>
>>> Thanks for your help!
>>> Stephen
>>>
>>> --
>>> www.stephen-lewis.net
>>>
>>
>>
>>
>> --
>> www.stephen-lewis.net
>>
>
>
>
> --
> www.stephen-lewis.net
