Thanks for your response. You were right, solr is logging to the catalina.out file for tomcat. When I click the optimize button in solr's admin interface the following logs are written: http://apaste.info/laup
About JVM memory, solr's admin interface is listing JVM memory at 3.1% (221.7MB is dark grey, 512.56MB light grey and 6.99GB total). On Mon, Oct 28, 2013 at 6:29 AM, Erick Erickson <erickerick...@gmail.com>wrote: > For Tomcat, the Solr is often put into catalina.out > as a default, so the output might be there. You can > configure Solr to send the logs most anywhere you > please, but without some specific setup > on your part the log output just goes to the default > for the servlet. > > I took a quick glance at the code but since the merges > are happening in the background, there's not much > context for where that error is thrown. > > How much memory is there for the JVM? I'm grasping > at straws a bit... > > Erick > > > On Sun, Oct 27, 2013 at 9:54 PM, Matthew Shapiro <m...@mshapiro.net> wrote: > > > I am working at implementing solr to work as the search backend for our > web > > system. So far things have been going well, but today I made some schema > > changes and now things have broken. > > > > I updated the schema.xml file and reloaded the core (via the admin > > interface). No errors were reported in the logs. > > > > I then pushed 100 records to be indexed. A call to Commit afterwards > > seemed fine, however my next call for Optimize caused the following > errors: > > > > java.io.IOException: background merge hit exception: > > _2n(4.4):C4263/154 _30(4.4):C134 _32(4.4):C10 _31(4.4):C10 into _37 > > [maxNumSegments=1] > > > > null:java.io.IOException: background merge hit exception: > > _2n(4.4):C4263/154 _30(4.4):C134 _32(4.4):C10 _31(4.4):C10 into _37 > > [maxNumSegments=1] > > > > > > Unfortunately, googling for background merge hit exception came up > > with 2 thing: a corrupt index or not enough free space. The host > > machine that's hosting solr has 227 out of 229GB free (according to df > > -h), so that's not it. > > > > > > I then ran CheckIndex on the index, and got the following results: > > http://apaste.info/gmGU > > > > > > As someone who is new to solr and lucene, as far as I can tell this > > means my index is fine. So I am coming up at a loss. I'm somewhat sure > > that I could probably delete my data directory and rebuild it but I am > > more interested in finding out why is it having issues, what is the > > best way to fix it, and what is the best way to prevent it from > > happening when this goes into production. > > > > > > Does anyone have any advice that may help? > > > > > > As an aside, i do not have a stacktrace for you because the solr admin > > page isn't giving me one. I tried looking in my logs file in my solr > > directory, but it does not contain any logs. I opened up my > > ~/tomcat/lib/log4j.properties file and saw http://apaste.info/0rTL, > > which didnt really help me find log files. Doing a 'find . | grep > > solr.log' didn't really help either. Any help for finding log files > > (which may help find the actual cause of this) would also be > > appreciated. > > >
