collective.recipe.solrinstance 5.0.0b3 does not work with Solr 4.10.x.

[tisto]

collective.recipe.solrinstance 5.0.0b3 / Solr 4.10.x fails with:

org.apache.solr.common.SolrException: Unable to use updateLog: _version_ field must exist in schema, using indexed="true" or docValues="true", stored="true" and multiValued="false" (_version_ does not exist)

Steps to reproduce.

Create package:

$ mrbob -O example.solr bobtemplates:plone_addon $ cd example.solr/ $ wget https://github.com/collective/collective.solr/raw/master/solr.cfg $ wget https://raw.githubusercontent.com/collective/collective.solr/master/solr-4.10.x.cfg

buildout.cfg:

[buildout]
extends =
    http://dist.plone.org/release/4.3.6/versions.cfg
    solr.cfg
    solr-4.10.x.cfg
...
parts +=

$ python bootstrap-buildout.py $ bin/buildout $ bin/solr-instance fg

org.apache.solr.common.SolrException: Unable to use updateLog: _version_ field must exist in schema, using indexed="true" or docValues="true", stored="true" and multiValued="false" (_version_ does not exist)
    at org.apache.solr.core.SolrCore.<init>(SolrCore.java:881)
    at org.apache.solr.core.SolrCore.<init>(SolrCore.java:654)
    at org.apache.solr.core.CoreContainer.create(CoreContainer.java:491)
    at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:255)
    at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:249)
    at java.util.concurrent.FutureTask.run(FutureTask.java:262)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:745)
Caused by: org.apache.solr.common.SolrException: Unable to use updateLog: _version_ field must exist in schema, using indexed="true" or docValues="true", stored="true" and multiValued="false" (_version_ does not exist)
    at org.apache.solr.update.UpdateLog.init(UpdateLog.java:280)
    at org.apache.solr.update.UpdateHandler.<init>(UpdateHandler.java:134)
    at org.apache.solr.update.UpdateHandler.<init>(UpdateHandler.java:94)
    at org.apache.solr.update.DirectUpdateHandler2.<init>(DirectUpdateHandler2.java:100)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
    at org.apache.solr.core.SolrCore.createInstance(SolrCore.java:558)
    at org.apache.solr.core.SolrCore.createUpdateHandler(SolrCore.java:628)
    at org.apache.solr.core.SolrCore.<init>(SolrCore.java:843)
    ... 8 more
Caused by: org.apache.solr.common.SolrException: _version_ field must exist in schema, using indexed="true" or docValues="true", stored="true" and multiValued="false" (_version_ does not exist)
    at org.apache.solr.update.VersionInfo.getAndCheckVersionField(VersionInfo.java:56)
    at org.apache.solr.update.VersionInfo.<init>(VersionInfo.java:82)
    at org.apache.solr.update.UpdateLog.init(UpdateLog.java:277)
    ... 18 more
2102 [main] INFO  org.apache.solr.servlet.SolrDispatchFilter  – user.dir=/home/timo/workspace/example.solr/parts/solr-instance
2102 [main] INFO  org.apache.solr.servlet.SolrDispatchFilter  – SolrDispatchFilter.init() done
2116 [main] INFO  org.eclipse.jetty.server.AbstractConnector  – Started SocketConnector@127.0.0.1:8983

Pinning c.r.solrinstance to 5.3.2 solves the issue.

Original bug report: https://github.com/collective/collective.solr/issues/84

[tisto]

I just made a collective.solr release and people will run into this when following the c.solr README. I either have to add a note to the c.solr README or we have to fix this in c.r.solrinstance. Is anybody working on c.r.solrinstance or feels responsible? This bug is open for 7 month...

[gforcada]

@tisto I deployed some days ago Solr in our website with a patched version of c.r.solr 5.3.x with one single fix.

I think that my fix (pointed above) is the solution to this problem, as there was no 5.3.x branch on c.r.solr I thought there's no desire on maintaining it as everyone(?) moved to master (6.x) releases.

[tisto]

@gforcada cool! I'm still on the 5.x branch with everything because 6.x never worked for me. Would you mind doing a pull request? I will create a 5.x branch...

[saily]

@tisto why did 6.x never work for you?

[tisto]

@saily because of the problem I described above. :) If people install the latest version of c.solr and follow the instructions, they will run into this problem. We can either solve it in p.r.solrinstance 6.x or add a note to the c.solr README that they need to pin to 5.x.

[saily]

a required _version_ field is not an issue of the recipe it's maybe an issue of the solrconfiguration. did you specify a solrconfig file?

[tisto]

@saily no, we are talking about the minimal c.solr standard buildout here:

https://raw.githubusercontent.com/collective/collective.solr/master/solr.cfg

[saily]

@tisto ok, then we should just disable updateLog and it works.

[tisto]

@saily you mean in the c.solr solr.cfg? This would mean that solr.cfg would work for c.r.solrinstance 5.x but not for 6.x, right?

[saily]

Using an update log requires a _version_ field in schema. Both versions are affected if updateLog=true is there.

[mauritsvanrees]

The title and the first comment talk about 5.0.0b3, but this is 6.0.0b3, right?

I tried it today with the minimal buildout and the solr-instance starts up just fine. This is on Mac. Any chance that the above error is only on Linux? No: I deployed solr 4.10.4 to an Ubuntu server with c.r.solrinstance 6.0.0b3, with a solr config based on the standard one.

The link between _version_ and updateLog seems just fine in our schema.xml template. Those lines are already in 6.0.0b3.