: Our number one problem: Doing a commit from loading records, which can : happen throughout the day, makes all queries stop for 5-7 seconds. : This is a showstopper for deployment.
Best guess: your queries rely on th FieldCache in some way (either sorting or faceting) and you aren't doing any cache warming that pre-populates that before exposing hte newSearcher to your users -- so when the commit finishes, the first query (and all similar qeries that want the FieldCache on the same field(s)) block until the fieldCache is built. Knowing what "pattern" your queries tend to follow (ie: what do you typically sort on, what do you typically facet on) and what your various cache configurations look like, and wether you have any "newSearcher" event listerners configured could help to determine if this is the problem. Second guess: your garbage collector settings are doing a "stop the world" garbage collection and right after a commit is when this tends to happen because there is a lot of new objects being created and a lot of garbage that can be collected. : dramatically. In general, what is the difference between accepting the : delay of waiting for warming vs. accepting the delay of running : useColdSearcher=true? useColdSearcher should only matter on the firstSearcher (server startup) when there is no other search available. -Hoss
