On 2/26/2014 11:22 PM, Thomas Scheffler wrote: > I am one developer of a repository framework. We rely on the fact, that > "SolrJ generally maintains backwards compatibility, so you can use a > newer SolrJ with an older Solr, or an older SolrJ with a newer Solr." [1] > > This statement is not even true for bugfix releases like 4.6.0 -> 4.6.1. > (SOLRJ 4.6.1, SOLR 4.6.0) > > We use SolrInputDocument from SOLRJ to index our documents (javabin). > But as framework developer we are not in a role to force our users to > update their SOLR server such often. Instead with every new version we > want to update just the SOLRJ library we ship with to enable latest > features, if the user wishes. > > When I send a query to a request handler I can attach a "version" > parameter to tell SOLR which version of the response format I expect. > > Is there such a configuration when indexing SolrInputDocuments? I did > not find it so far.
What problems have you seen with mixing 4.6.0 and 4.6.1? It's possible that I'm completely ignorant here, but I have not heard of any. A full discussion of this topic could fill a short novel. This reply is a little long, but hopefully digestible. I am assuming that you have a fair amount of familiarity with SolrJ here. If there's something you don't understand or seems wrong, we'll explore further. The javabin format changed between 1.4.1 and the next version (3.1) in a way that is incompatible in either direction, so mixing those versions requires using XMLResponseWriter. The javabin format has remained unchanged since version 3.1. Because Solr 1.x is very old and has the javabin incompatibility with later releases, I will not be discussing it beyond what I wrote above. You mentioned the version parameter. SolrJ automatically handles this in the requests it makes to Solr. You don't need to worry about it. One of the first things to say is that if you are using SolrCloud with the CloudSolrServer object, the only way that you can have any assurance of success with mixed versions is if your SolrJ version is newer than your Solr version, and I would not be assured very far unless the minor version is the same between the two. SolrCloud is evolving at an incredible pace. As far as I know, *backwards* compatibility is pretty good, but I would not be surprised to learn that there are some hiccups. I don't have a lot of experience with CloudSolrServer yet. Cross-version compatibility with non-cloud setups is MUCH better. A non-cloud setup is assumed for the rest of this email. I think it's important to mention that ConcurrentUpdateSolrServer and its predecessor StreamingUpdateSolrServer are usually not a good choice, unless you don't care about error handling. These classes do NOT inform the calling application of any error that occurs when sending updates to Solr. Rather than rely on one of these methods for making requests in parallel, your application should be multithreaded and send parallel requests itself with HttpSolrServer, which is completely threadsafe. If you're mixing 3.x and 4.x versions, stick to the xml REQUEST writer. This is the default in all but the most recent versions of SolrJ, but it's actually a good idea to explicitly set the writer object so you won't be surprised by an upgrade. You can use the binary RESPONSE writer (which is the default in all versions) with no problem. If both versions are 4.x, binary is fine for both the request writer and the response writer, and for performance reasons, is the preferred choice. In non-cloud setups, there are very few problems to be found with any combination of 4.x versions. Thanks. Shawn
