lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shahar Davidson <shah...@checkpoint.com>
Subject RE: Invalid version (expected 2, but 60) or the data in not in 'javabin'
Date Wed, 26 Dec 2012 09:42:59 GMT
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:markrmiller@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 <shahard@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.gospodnetic@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 <shahard@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

Mime
View raw message