Why does it matter? The whole idea of firstSearcher queries is to warm up your system as fast as possible. The theory is that upon restarting the server, let's bet this stuff going immediately... They were never intended (as far as I know) to complete before any queries were handled. As an aside, I'm not quite sure I understand why pings during the warmup are a problem.
But anyway. firstSearcher is particularly relevant because the autowarmCount settings on your caches are irrelevant when starting the server, there's no history to autowarm.... But, there's no good reason _not_ to let queries through while firstSearcher is doing it's tricks, they just get into the queue and are served as quickly as they may. That might be some time since, as you say, they may not get serviced until the expensive parts get filled. But I don't think having them be serviced is doing any harm. Now, newSearcher and autowarming of the caches is a completely different beast since having the old searchers continue serving requests until the warmups _does_ directly impact the user, they don't see random slowness because a searcher is being opened. So I guess my real question is whether you're seeing a measurable problem or if this is a red herring.... FWIW, Erick On Thu, Nov 8, 2012 at 2:54 PM, Aaron Daubman <daub...@gmail.com> wrote: > Greetings, > > I have several custom QueryComponents that have high one-time startup costs > (hashing things in the index, caching things from a RDBMS, etc...) > > Is there a way to prevent solr from accepting connections before all > QueryComponents are "ready"? > > Especially, since many of our instance are load-balanced (and > added-in/removed automatically based on admin/ping responses) preventing > ping from answering prior to all custom QueryComponents being ready would > be ideal... > > Thanks, > Aaron >
