Hello, I still have this issue using Solr 4.4, removing firstSearcher queries did make the problem go away.
Note that I'm using Tomcat 7 and that if I'm using my own Java application launching an Embedded Solr Server pointing to the same Solr configuration the server fully starts with no hang. What is the xml tag syntax to have spellcheck=false for firstSearcher discussed above? Cheers, /jonatan --- HANG with Tomcat 7 (firstSearcher queries on) --- <...> 2409 [coreLoadExecutor-3-thread-3] INFO org.apache.solr.handler.component.SpellCheckComponent – No queryConverter defined, using default converter 2409 [coreLoadExecutor-3-thread-3] INFO org.apache.solr.handler.component.QueryElevationComponent – Loading QueryElevation from: /var/lib/myapp/conf/elevate.xml 2415 [coreLoadExecutor-3-thread-3] INFO org.apache.solr.handler.ReplicationHandler – Commits will be reserved for 10000 2415 [searcherExecutor-16-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener sending requests to Searcher@5c43ecf0main{StandardDirectoryReader(segments_3:23 _9(4.4):C57862)} 2417 [searcherExecutor-16-thread-1] INFO org.apache.solr.core.SolrCore – [foo-20130912] webapp=null path=null params={event=firstSearcher&q=static+firstSearcher+warming+in+solrconfig.xml&distrib=false} hits=0 status=0 QTime=1 2417 [searcherExecutor-16-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener done. 2417 [searcherExecutor-16-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: default 2417 [searcherExecutor-16-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: wordbreak 2418 [searcherExecutor-16-thread-1] INFO org.apache.solr.core.SolrCore – [foo-20130912] Registered new searcher Searcher@5c43ecf0main{StandardDirectoryReader(segments_3:23 _9(4.4):C57862)} 2420 [coreLoadExecutor-3-thread-3] INFO org.apache.solr.core.CoreContainer – registering core: foo-20130912 --- NO HANG EmbeddedSolrServer (firstSearcher queries on) --- <...> 1797 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – No queryConverter defined, using default converter 1797 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.handler.component.QueryElevationComponent – Loading QueryElevation from: /var/lib/myapp/conf/elevate.xml 1800 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.handler.ReplicationHandler – Commits will be reserved for 10000 1801 [searcherExecutor-15-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener sending requests to Searcher@27b104d7main{StandardDirectoryReader(segments_3:23 _9(4.4):C57862)} 1801 [searcherExecutor-15-thread-1] INFO org.apache.solr.core.SolrCore – QuerySenderListener done. 1801 [searcherExecutor-15-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: default 1801 [coreLoadExecutor-3-thread-1] INFO org.apache.solr.core.CoreContainer – registering core: foo-20130912 1801 [searcherExecutor-15-thread-1] INFO org.apache.solr.handler.component.SpellCheckComponent – Loading spell index for spellchecker: wordbreak 1801 [searcherExecutor-15-thread-1] INFO org.apache.solr.core.SolrCore – [foo-20130912] Registered new searcher Searcher@27b104d7main{StandardDirectoryReader(segments_3:23 _9(4.4):C57862)} On Fri, Sep 6, 2013 at 4:29 PM, Austin Rasmussen <arasmus...@directs.com>wrote: > : Do all of your cores have "newSearcher" event listners configured or just > : 2 (i'm trying to figure out if it's a timing fluke that these two are > stalled, or if it's something special about the configs) > > All of my cores have both the "newSearcher" and "firstSearcher" event > listeners configured. (The firstSearcher actually doesn't have any queries > configured against it, so it probably should just be removed altogether) > > : Can you try removing the newSearcher listners to confirm that that does > in fact make the problem go away? > > Removing the "newSearcher" listeners does not make the problem go away; > however, removing the "firstSearcher" listener (even if the "newSearcher" > listener is still configured) does make the problem go away. > > : With the newSearcher listeners in place, Can you try setting > "spellcheck=false" as a query param on the newSearcher listeners you have > configured and > : see if that works arround the problem? > > Adding the "spellcheck=false" param to the "firstSearcher" listener does > appear to work around the problem. > > : Assuming it's just 2 cores using these listeners: can you reproduce this > problem with a simpler seup where only one of the affected cores is in use? > > Since it's not just these two cores, I'm not sure how to produce much of a > simpler setup. I did attempt to limit how many cores are loaded in the > solr.xml, and found that if I cut it down to 56, it was able to load > successfully (without any of the above config changed). > > If I cut it down to 57 cores, it doesn't hang at "registering core" any > more, it actually gets as far as " QuerySenderListener sending requests to > Searcher@2f28849 main{StandardDirectoryReader(..." > > If 58+ cores are loaded at start up, that's when it begins to hang at > "registering core". However, it always hangs on the *last* core configured > in the solr.xml, regardless of how many cores are being loaded. > > > : can you reproduce using Solr 4.4? > : It would be helpful if you could create a jira and attach... > : * your complete configs -- or at least some configs similar to yours > that are complete enough to reproduce the startup problem. > : * some sample data (based on > : your initial description, i'm guessing there at least needs to be a > handful of docs in the index -- and most likelye they need to match your > warming query -: - but we don't need your actual indexes, just some docs > that will work with your configs that we can index > : & restart to see the problem. > : * these thread dumps. > > I can likely get to this early next week, both checking into how this > behaves using Solr 4.4 and submitting a JIRA with your requested info. >