Oh, one more thing. Would this setup still be possible if we would want to have 
the new 5.x solr server be the solr cloud version? I'm not saying that 
SolrCloud is a requirement for us (it might even not be suitable, since our 
index is not that large), but still would be good to know.

/Jimi

-----Original Message-----
From: jimi.hulleg...@svensktnaringsliv.se 
[mailto:jimi.hulleg...@svensktnaringsliv.se] 
Sent: Friday, January 22, 2016 11:03 PM
To: solr-user@lucene.apache.org
Subject: RE: Mix Solr 4 and 5?

OK, so just to be clear. As far as you know, and from your point of view, you 
would consider it a better solution to stick with the 4.6 solrj client jar for 
both the 4.6 and 5.x communication, rather than switching the 4.6 solrj client 
jar to the 5.x version and hoping that the CMS solr-specific code (written with 
4.x in mind) still would work?

And by the way, thanks for all the feedback and input all you guys. I really 
appreciate it.
/Jimi

-----Original Message-----
From: Jack Krupansky [mailto:jack.krupan...@gmail.com]
Sent: Friday, January 22, 2016 10:52 PM
To: solr-user@lucene.apache.org
Subject: Re: Mix Solr 4 and 5?

Personally, I think the Solr project should endeavor to commit to guaranteeing 
that a SolrJ x.y client will be compatible with a Solr x+1.y2 Solr server. 
AFAICT there currently isn't such a formal compat commitment or promise, but 
also AFAIK there is no known non-compat issue between SolrJ 4.y and Sol 5.y2. 
Let's see if anybody else knows of any. There might be issues if you do extreme 
things like examining the detailed cluster state from Zookeeper or use some of 
the non-traditional APIs introduced since 4.6 that may have been works in 
progress, but as long as you keep your app usage of these more advanced 
features to a minimum, you should be able to sidestep such issues.

If you try it and do run into a compat issue, we should make an effort to 
consider that an unacceptable bug since upgrading clients is not always such an 
easy or even feasible process, and if the old clients aren't using any new 
features there would be a reasonable expectation that they should continue to 
work.


-- Jack Krupansky

On Fri, Jan 22, 2016 at 10:40 AM, <jimi.hulleg...@svensktnaringsliv.se>
wrote:

> Yeah, sort of. Solr isn't bundled in the CMS, it is in a separate 
> Tomcat instance. But our code is running on the same Tomcat as the 
> CMS, and the CMS uses solrj 4.x to talk with its solr. And now we want 
> to be able to talk with our own separate solr, running solr 5.x, and 
> would prefer to use solrj for this.
>
> /Jimi
>
> -----Original Message-----
> From: Jack Krupansky [mailto:jack.krupan...@gmail.com]
> Sent: Friday, January 22, 2016 10:11 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Mix Solr 4 and 5?
>
> Just to be clear, are you talking about a single app that does SolrJ 
> calls to both your CMS and your free text search index? So, one Java 
> app that is simultaneously sending requests to two Solr instances (once 4, 
> one 5)?
>
> -- Jack Krupansky
>
> On Fri, Jan 22, 2016 at 1:57 AM, <jimi.hulleg...@svensktnaringsliv.se>
> wrote:
>
> > Hi,
> >
> > 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.
> >
> > What would you say that our options are? I would really not like 
> > having do low level http calls to the solr 5 server.
> >
> > Regards
> > /Jimi
> >
>

Reply via email to