Just to give folks an update, we trashed the server having issues and
cloned/rebuild a VM from a sane server and it seems to be running good
for the past 3 days without any issues. We intend to monitor it over
the weekend. If its still stable on Monday, I would blame the issues
it on the server con
I have already triple cross-checked that all my clients are using
same version as the server which is 3.6
Thanks
Ravi Kiran
On Tue, May 15, 2012 at 2:09 PM, Ramesh K Balasubramanian
wrote:
> I have seen similar errors before when the solr version and solrj version in
> the client don't match.
I have seen similar errors before when the solr version and solrj version in
the client don't match.
Best Regards,
Ramesh
Hello,
Unfortunately it seems like I spoke too early. Today morning I
received the same error again even after disabling the iptables. The
weird thing is only one out of 6 or 7 queries fails as evidenced in
the stack traces below. The query below the stack trace gave a
'status=500' subsequen
Yeah, 9 times out of 10, this error is a 404 - which wouldn't be logged
anywhere.
On May 11, 2012, at 6:12 PM, Ravi Solr wrote:
> Guys, just to give you an update, we think we "might" have found the
> issue. iptables was enabled on one query server and disabled on the
> other. The server where i
Guys, just to give you an update, we think we "might" have found the
issue. iptables was enabled on one query server and disabled on the
other. The server where iptables is enabled is the one having issues,
we disabled the iptables today to test out the theory that the
iptables might be causing thi
On 5/10/2012 4:17 PM, Ravi Solr wrote:
Thanks for responding Mr. Heisey... I don't see any parsing errors in
my log but I see lot of exceptions like the one listed belowonce
an exception like this happens weirdness ensues. For example - To
check sanity I queried for uniquekey:"111" from the s
Thanks for responding Mr. Heisey... I don't see any parsing errors in
my log but I see lot of exceptions like the one listed belowonce
an exception like this happens weirdness ensues. For example - To
check sanity I queried for uniquekey:"111" from the solr admin GUI it
gave back numFound equal
On 5/10/2012 12:27 PM, Ravi Solr wrote:
I clean the entire index and re-indexed it with SOLRJ 3.6. Still I get
the same error every single day. How can I see if the container
returned partial/nonconforming response since it may be hidden by
solrj ?
If the server is sending a non-javabin error r
I clean the entire index and re-indexed it with SOLRJ 3.6. Still I get
the same error every single day. How can I see if the container
returned partial/nonconforming response since it may be hidden by
solrj ?
Thanks
Ravi Kiran Bhaskar
On Mon, May 7, 2012 at 2:16 PM, Ravi Solr wrote:
> Hello Mr.
Hello Mr. Miller and Mr. Erickson,
Found yet another inconsistency on the query server that
might be causing this issue. Today morning also I got a similar error
as shown in stacktrace below. So I tried querying for that
"d101dd3a-979a-11e1-927c-291130c98dff" which is our unique key i
Normally this specific error is caused by a non success http error page and
response is returned. The response parser tries to parse HTML as javabin.
Sent from my iPhone
On May 7, 2012, at 7:37 AM, Erick Erickson wrote:
> Well, I'm guessing that the version of Solr (and perhaps there are
> cl
Well, I'm guessing that the version of Solr (and perhaps there are
classpath issues in here?) are different, somehow, on the machine
slave that is showing the error.
It's also possible that your config files have a different LUCENE_VERSION
in them, although I don't think this should really create
Thank you very much for responding Mr.Erickson. You may be right on
old version index, I will reindex. However we have a 2
separate/disjoint master-slave setup...only one query node/slave has
this issue. if it was really incompatible indexes why isnt the other
query server also throwing errors? tha
The first thing I'd check is if, in the log, there is a replication happening
immediately prior to the error. I confess I'm not entirely up on the
version thing, but is it possible you're replicating an index that
is built with some other version of Solr?
That would at least explain your statement
Hello,
We Recently we migrated our SOLR 3.6 server OS from Solaris
to CentOS and from then on we started seeing "Invalid version
(expected 2, but 60)" errors on one of the query servers (oddly one
other query server seems fine). If we restart the server having issue
everything will be alri
16 matches
Mail list logo
