Yes, I am hitting the Solr server directly (medsolr1.colo:9007) Versions / architectures:
Jetty(6.1.3) o...@medsolr1 ~ $ uname -a Linux medsolr1 2.6.18-xen-r12 #9 SMP Tue Mar 3 15:34:08 PST 2009 x86_64 Intel(R) Xeon(R) CPU L5420 @ 2.50GHz GenuineIntel GNU/Linux o...@medsolr1 ~ $ java -version java version "1.6.0_11" Java(TM) SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) 64-Bit Server VM (build 11.0-b16, mixed mode) I was thinking of trying LucidWorks for Solr (1.3.02) x64 - worth a try. -Rupert On Fri, Aug 28, 2009 at 3:08 PM, Yonik Seeley<ysee...@gmail.com> wrote: > On Mon, Aug 24, 2009 at 6:30 PM, Rupert Fiasco<rufia...@gmail.com> wrote: >> If I run these through curl on the command its >> truncated and if I run the search through the web-based admin panel >> then I get an XML parse error. > > Are you running curl directly against the solr server, or going > through a load balancer? Cutting out the middle-men using curl was a > great idea - just make sure to go all the way. > > At first I thought it could possibly be a FastWriter bug (internal > Solr class), but that's only used on the TextWriter (JSON, Python, > Ruby) based formats, not on the original XML format. > > It really looks like you're hitting a lower-level IO buffering bug > (esp when you see a response starting off with the tail of another > response). That doesn't look like it could be a Solr bug... but > rather smells like a thread safety bug in the servlet container. > > What type of machine are you running on? What JVM? > You could try upgrading your version of Jetty, the JVM, or try > switching to Tomcat. > > -Yonik > http://www.lucidimagination.com > > >> This appears to have just started recently and the only thing we have >> done is change our indexer from a PHP one to a Java one, but >> functionally they are identical. >> >> Any thoughts? Thanks in advance. >> >> - Rupert >> >
