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.
>
