Thanks for the prompt reply Mark. Just to give you some background, I'm simulating a multi-shard environment by running more than 200 Solr Cores on a single machine (machine does not seem to be stressed) and I'm running a distributed facet. The Solr server is running trunk 1404975 with SOLR-2894 patch applied over it (the one from Nov. 12th). While I'm running the distributed request, other clients are sending various search requests to the Solr server. This issue is randomly happening and does not reproduce constantly. As I wrote earlier, I applied the Debugging.patch from SOLR-3258 to see the actual response and noticed that an actual XML reply was received and the XML itself was corrupt (as if a chunk of text was taken out right from the middle of it).
Since this reproduces randomly, the only thing that comes to mind is some kind of concurrency related problem. Any help would be greatly appreciated, Shahar. -----Original Message----- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Wednesday, December 26, 2012 4:21 AM To: solr-user@lucene.apache.org Subject: Re: Invalid version (expected 2, but 60) or the data in not in 'javabin' The problem is not necessary xml - it seems to be anything that is not valid javabin - I've just most often seen it with 404s that return an html error. I'm not sure if there is a jira issue or not, but this type of thing should be failing in a more user friendly way. As to why your response is corrupt, I have no guesses. This is easily repeatable? It's happening every time, or randomly? - Mark On Dec 25, 2012, at 4:23 AM, Shahar Davidson <shah...@checkpoint.com> wrote: > Thanks Otis. > > I went through every piece of info that I could lay may hands on. > Most of them are about incompatible SolrJ versions (that's not my case) and > there was one message from Mark Miller that Solr may respond with an XML > instead of javabin in case there was some kind of http error being returned > (that's not my case either). > > I'm using distributed search. > I added some debug output to print out the response once the "Invalid > version" exception is caught (in JavaBinCode.unmarshal() ). > What I saw is that the response actually contains the facet response in XML > format, yet I also noticed that the response is corrupt (i.e. as if a chunk > of text has been taken out of the middle of the reply - some kind of overrun > perhaps?). > > Any help would be appreciated. > > Thanks, > > Shahar. > > > -----Original Message----- > From: Otis Gospodnetic [mailto:otis.gospodne...@gmail.com] > Sent: Friday, December 21, 2012 6:23 AM > To: solr-user@lucene.apache.org > Subject: Re: Invalid version (expected 2, but 60) or the data in not in > 'javabin' > > Hi, > > Have a look at http://search-lucene.com/?q=invalid+version+javabin > > Otis > -- > Solr Monitoring - http://sematext.com/spm/index.html > Search Analytics - http://sematext.com/search-analytics/index.html > > > > > On Wed, Dec 19, 2012 at 11:23 AM, Shahar Davidson > <shah...@checkpoint.com>wrote: > >> Hi, >> >> I'm encountering this error randomly when running a distributed facet. >> (i.e. I'm sending the exact same request, yet this does not reproduce >> consistently) >> I have about 180 shards that are being queried. >> It seems that when Solr distributes the request to the shards one , >> or perhaps more, shards return an XML reply instead of Javabin. >> >> I added some debug output to JavaBinCode.unmarshal (as done in the >> debugging.patch of SOLR-3258) to check whether the XML reply holds an >> error or not, and I noticed that the XML actually holds the response >> from one of the shards. >> >> I'm using the patch provided in SOLR-2894 on top of trunk 1404975. >> >> Has anyone encountered such an issue? Any ideas? >> >> Thanks, >> >> Shahar. >> > > > Email secured by Check Point Email secured by Check Point
