Peter,
Thanks for taking the time to spell out what you were going through. It's great to have details like to to mull over. Jason On 2013-05-14 12:44, Lee, Peter wrote: > Thank you one and all for your input. > > The problem we were tripping over turned out NOT to be related to using solrj 3.5 client and solr 4.2.1 server. We are, as of this minute, feeling confident we can put this into production. We are still doing some testing, but thus far we have hit all of the big hitters and they have all performed great. > > The only problems we have tripped over have to do with the changes in Solr config files (understandable) and also changes in how solr behaves in certain conditions. For example, the problem we just tracked down had to do with the fact that solr was giving us successful return codes but returning no matches...no matter what we did. > > The cause: > We had an unintentional case that occurred through one request handler such that after the query was processed through the RH and the parameters were set, there were fq variables set but no actual "q" (query) param. > - Under solr 3.5, solr seems to assume you MEANT to specify q=*:* > - Under solr 4.2.1, solr makes no such assumption (or so it seems). It appears as if solr has decided that since we didn't bother to include a 'q' parameter, it isn't going to bother to search for anything (yes, I'm anthropomorphizing...it was a late night). I tried the same query with the same request handler back and forth between the two versions of solr server and one returned my data set and the other gave me zero hits. > > This kind of behavior change between 3.5 and 4.2.1 has caused us the most stumbles. Solrj 3.5 seems to work just fine for our use (which, as stated before, is very simple). Again I will state that our use of solrj is only at runtime, and we have only been sending very simple queries (no indexing occurring through solrj 3.5) that are either exact match or else simple analyzed text fields. > > For these limited searches we are feeling confident to go to production with this setup. We hope to have the solrj version upgraded (which requires a java upgrade, which requires work on the application as we've already determined that it won't work correctly on Java 7) in the near future and then we won't have to worry about it any longer. > > I hope this information is of help to you or anyone else reading this thread. I appreciate all of the comments people have made to assist us in this matter. > > Thank you. > > Peter S. Lee > > -----Original Message----- > From: Robert J. Haschart [mailto:rh...@virginia.edu] > Sent: Sunday, May 12, 2013 11:29 PM > To: solr-user@lucene.apache.org > Subject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1 > > Peter, > > In the work I have done for the project SolrMarc, which various sites use to index Marc records into Solr. It ships as a binary version that includes a slightly modified version of solrj 3.5, which it uses to communicate with > whatever version of solr that site uses. It can operate with solr 1.4, > solr 3.x, and at least solr 4.0 and solr 4.1 (and in all likelihood solr > 4.2 as well). I will check tomorrow to find what specific changes were > needed for it to work with solr 4.x. > > -Bob > > On Mon, 13 May 2013 02:11:02 +0000 > "Lee, Peter" <peter....@proquest.com> wrote: > >> Shawn, Thanks for the feedback. I did read carefully through your thread before I posted as it looked close...but as you say..."backwards"...to what we are trying to do. Fortunately for us, "commit" doesn't enter the picture. Our index at runtime is effectively "read only," and the indexing and committing are done by programs that don't need to use the older solrj (3.5) version. It is our runtime application that we need to see if we can get to run on solrj 3.5 for a short time longer. I *do* think our 3.5 client is using javabin, so I will look at your suggested work around. All had been going well but we just hit a bump in the road and we are investigating now. Your information may turn out to be invaluable. Either way it is greatly appreciated. Thanks again for your help. Peter Lee -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: Sunday, May 12, 2013 1:22 AM To: solr-user@lucene.apache.orgSubject: Re: Looking to see if solrj 3.5 could be used with solr server 4.2.1 On 5/11/2013 9:36 PM, Lee, Peter wrote: >> >>> I've reviewed all of the release notes and we've been doing testing to see if solrj that came with solr 3.5 would work with solr server 4.2.1. We are not using any of the new features of 4.2.1...we upgraded purely for the improved performance and much smaller memory footprint of the indexes. While I have not identified anything in the release notes that looks like a deal breaker, I also realize that the powers that be may be thinking that this is such a no brainer question (why would ANYONE want to use solrj 3.5 with solr 4.2.1) that it simply was assumed obvious and did not need stating. >> Initial note: There might be a showstopper with commit. I'm building a test program now to see. Assuming that is all clear, then the following will apply: We've just been having a discussion about this very thing, though in the other direction - SolrJ 4.2.1 and Solr 3.x. From the research and experimentation I've done both in the past and for the recent discussion, as long as you don't try to set the request writer to Binary, it should work with a fairly vanilla Solr 4.x config. If you define the /update/javabin handler in your Solr 4.x config, it should work even if you are using the binary request writer. <requestHandler name="/update/javabin" class="solr.BinaryUpdateRequestHandler" /> Most potential problems are likely to be things that you can work out by adjusting the server config. Thanks, Shawn
