The default jetty.xml sets up a request logger that logs to
"logs/_mm_dd.request.log" relative to the directory jetty is
started from. Look for NCSARequestLog in your jetty.xml. If SOLR
Sharp uses GETs (not POSTs) you can look at the urls in the log and
pull out the "q" and "fq" parameters wh
The error might be that your http client doesn't handle really large
files (32-bit overflow in the Content-Length header?) or something in
your network is killing your long-lived socket? Solr can definitely
accept a 13GB xml document.
I've uploaded large files into Solr successfully, including re
s working on something very similar... Lets perhaps also create a
> Jira issue for this monitoring?
>
> Thanks,
>
> Jason
>
> On Fri, Mar 26, 2010 at 6:59 AM, Shawn Smith wrote:
>> We're using Solr 1.4 Java replication, which seems to be working
>> nicely.
Thanks. I created https://issues.apache.org/jira/browse/SOLR-1853
2010/3/27 Noble Paul നോബിള് नोब्ळ् :
> please create a bug
>
What's the recommendation for the best way for detecting replication
slave replication health, using Solr 1.4 Java replication? The
current "details" command returns a lot of useful data, but it's not
obvious how best to extract the answer to the simple question: "is
replication ok, slow or failed
We're using Solr 1.4 Java replication, which seems to be working
nicely. While writing production monitors to check that replication
is healthy, I think we've run into a bug in the status reporting of
the "../solr/replication?command=details" command. (I know it's
experimental...)
Our monitor pa
