lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Krupansky <>
Subject Re: Mix Solr 4 and 5?
Date Fri, 22 Jan 2016 15:37:11 GMT
The doc is silent on this issue of SolrJ vs. server version compatibility
in general (e.g., 4 vs. 5.) That's not an absolute assurance, but at least
it's a possibility. And and far as I know, if you had a SolrJ 4 app and
upgraded the server (with no change in the index or data model), the app
should work fine. So... if you stick with SolrJ 4 and use the Solr 4 doc as
your guide, you should be okay. That's the theory.

Worst case, you would have to deploy a Solr 4 server. That's not the
preferred choice, but is a decent backup plan.

-- Jack Krupansky

On Fri, Jan 22, 2016 at 10:19 AM, Shawn Heisey <> wrote:

> On 1/21/2016 11:57 PM, wrote:
> > Long story short, we use a CMS that is integrated with Solr 4.6, with
> the solrj jar file in the global/common Tomcat classpath. We currently use
> a Google Search Appliance machine for our own freetext search needs, but
> plan to replace that with some other solution in the near future. Since we
> already work with solr because of the CMS integration, we would like to
> select solr for this project.
> >
> > But I would prefer to use the latest version, ie solr 5, and I am not
> sure how that would work in our situation. Can we use the solrj client for
> solr 4 when indexing and searching on a solr 5 server? If so, would we miss
> some important feature, and would this setup be future proof?
> >
> > Or can we somehow use both solr4 and solr 5 client libraries at the same
> time, in the same context? It is not possible to upgrade the solr server
> that the CMS is using, and it is not possible to remove the 4.6 solrj jar
> from the common classpath in Tomcat. That is, unless the solr 5 version of
> solrj is backwards compatible, so that we can switch the jar files and our
> CMS would still be able to index and search in it's own solr 4 server.
> If you are NOT running SolrCloud, then that should work with no
> problem.  The HTTP API is fairly static and has not seen any major
> upheaval recently.  If you're NOT running SolrCloud, you may even be
> able to replace the SolrJ jar in your existing system with the 5.4.1
> version (and update SolrJ's dependent jars) and have everything continue
> to work.
> If you ARE running SolrCloud, I would not try mixing 4.x and 5.x, in
> either direction.  SolrCloud is evolving very quickly ... I wouldn't
> even mix *minor* versions, much less *major* versions.  There are
> differences in how the zookeeper database is laid out, and mixing
> versions is not guaranteed to work, especially if SolrJ is older than
> Solr.  If the version difference is small and SolrJ is newer than Solr,
> there's a chance of success, but with the situation you have described,
> SolrCloud would likely not work.
> I have no idea about whether or not you can mix SolrJ versions in your
> client project.  This is extremely tricky to get working right with Java
> in general, and may not be possible.
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message