On 1/29/2015 11:37 PM, Clemens Wyss DEV wrote: >> The recommendation these days is to NOT use the embedded server > We would love to, as it is clear that this is not the "Solr-way" to go. The > reason for us building upon EmbeddedSolrServer is, we have more than > 150sites, each with ist own index (core). If we'd go client server then we > could no easily update the solr server(s) without also updating all clients > (i.e. the 150 sites) at same time. And having a dedicated Solr server for > every client/site is not really an option, is it? > > Or can for example a 4.10.3 client "talk" to a Solr 5/6 Server? Also when > updating the Solr server, doesn't that also require a re-index of all data as > the Luncene-storage format might have changed?
Cross-version compatibility between SolrJ and Solr is very high, as long as you're not running SolrCloud. SolrCloud is *incredibly* awesome, but it's not for everyone. Without SolrCloud, the communication is http only, using very stable APIs that have been around since pretty much the beginning of Solr. In the 1.x and 3.x days, there were occasional code tweaks required for cross-version compatibility, but the API has been extremely stable since early 4.x -- for a couple of years now. SolrCloud is much more recent and far more complex, so problems or deficiencies are sometimes found with the API. Fixing those bugs sometimes requires changes that are incompatible with other versions of the Java client. The SolrJ java client is an integral part of Solr itself, so SolrCloud functionality in the client is tightly coupled to specifics in the API that are undergoing rapid change from version to version. I don't think that SolrCloud is even possible with the embedded server, because it requires HTTP for inter-server communication. The embedded server doesn't listen for HTTP. Thanks, Shawn
