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
Thank you very much for responding Mr. Miller. There are 5 different
apps deployed on the same server as SOLR and all apps call SOLR as via
SOLRJ with localhost:8080/solr/sitecore as constructor url for
HttpSolrServer.out of all these 5 apps only one has this
issueif it is really the web se
On May 4, 2012, at 4:09 PM, Ravi Solr wrote:
> Thanking you in anticipation,
Generally this happens because the webapp server is returning an html error
response of some kind. Often it's a 404.
I think in trunk this might have been addressed - that is, it's easier to see
the true error. Not p
17 matches
Mail list logo
