You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Steve Woodcock <st...@gmail.com> on 2013/04/16 12:35:27 UTC

SEVERE: shard update error StdNode on SolrCloud 4.2.1

Hi

We have a simple SolrCloud setup (4.2.1) running with a single shard and
two nodes, and it's working fine except whenever we send an update request,
the leader logs this error:

SEVERE: shard update error StdNode:
http://10.20.10.42:8080/solr/ts/:org.apache.solr.common.SolrException:
Server at http://10.20.10.42:8080/solr/ts returned non ok status:500,
message:Internal Server Error
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:373)
...

Which triggers a lot of to-ing and fro-ing between the leader and the
replica, starting with this response on the replica to the above:

INFO: [ts] webapp=/solr path=/update params={distrib.from=
http://10.20.10.29:8080/solr/ts/&update.distrib=FROMLEADER&wt=javabin&version=2}
{} 0 12
15-Apr-2013 16:38:23 org.apache.solr.common.SolrException log
SEVERE: java.lang.UnsupportedOperationException
at
org.apache.lucene.queries.function.FunctionValues.longVal(FunctionValues.java:46)
at
org.apache.solr.update.VersionInfo.getVersionFromIndex(VersionInfo.java:201)
at org.apache.solr.update.UpdateLog.lookupVersion(UpdateLog.java:714)
at org.apache.solr.update.VersionInfo.lookupVersion(VersionInfo.java:184)
...

At this point, the leader tells the replica to recover:

INFO: try and ask http://10.20.10.42:8080/solr to recover

Which it does:

15-Apr-2013 16:38:23 org.apache.solr.handler.admin.CoreAdminHandler
handleRequestRecoveryAction

but the attempt to use PeerSync fails:

INFO: Attempting to PeerSync from http://10.20.10.29:8080/solr/ts/ core=ts
- recoveringAfterStartup=false
15-Apr-2013 16:38:26 org.apache.solr.update.PeerSync sync
INFO: PeerSync: core=ts url=http://10.20.10.42:8080/solr START replicas=[
http://10.20.10.29:8080/solr/ts/] nUpdates=100
15-Apr-2013 16:38:26 org.apache.solr.update.PeerSync handleVersions
INFO: PeerSync: core=ts url=http://10.20.10.42:8080/solr  Received 100
versions from 10.20.10.29:8080/solr/ts/
15-Apr-2013 16:38:26 org.apache.solr.update.PeerSync handleVersions
INFO: PeerSync: core=ts url=http://10.20.10.42:8080/solr  Our versions are
too old. ourHighThreshold=1432379781917179904
otherLowThreshold=1432382177294680064
15-Apr-2013 16:38:26 org.apache.solr.update.PeerSync sync
INFO: PeerSync: core=ts url=http://10.20.10.42:8080/solr DONE. sync failed
15-Apr-2013 16:38:26 org.apache.solr.cloud.RecoveryStrategy doRecovery
INFO: PeerSync Recovery was not successful - trying replication. core=ts

Replication then proceeds correctly, and the node is brought up to date.

I'm guessing it's not supposed to work like this, but I'm having trouble
finding anyone else with this problem, which makes me suspect we configured
it wrong somewhere along the line, but I've checked it all per the
documentation and I'm starting to run out of ideas.

Any suggestions for where to look next would be most appreciated!

Regards, Steve Woodcock

Re: SEVERE: shard update error StdNode on SolrCloud 4.2.1

Posted by Steve Woodcock <st...@gmail.com>.
On 16 April 2013 11:35, Steve Woodcock <st...@gmail.com> wrote:

> We have a simple SolrCloud setup (4.2.1) running with a single shard and
> two nodes, and it's working fine except whenever we send an update request,
> the leader logs this error:
>
> SEVERE: shard update error StdNode:
> http://10.20.10.42:8080/solr/ts/:org.apache.solr.common.SolrException:
> Server at http://10.20.10.42:8080/solr/ts returned non ok status:500,
> message:Internal Server Error
>  at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:373)
>

Turns out I think this was caused by having the wrong type for the
_version_ field in the schema. We had type="string", but should be
type="long", ie.

  <field name="_version_" type="long" indexed="true" stored="true"
multiValued="false"/>

Which, to be fair, is well documented at
http://wiki.apache.org/solr/SolrCloud

Certainly seems to be working a lot better so far ...

Cheers, Steve