: I suspect this has something to do with waiting for the searcher to : warm and switch over (?). Though, I'm confused because when I print : out /solr/admin/registry.jsp, the hashcode of the Searcher changes : immediately (as the commit docs say, the commit operation blocks by : default until a new searcher is in place). I've tried turning off all : caching, to no effect.
off the top of my head i don't remember if registry.jsp will start to list hte new searcher even if it's not swapped in to become hte current searcher. what you should check, is when the slave logs hte end of the commit, and how long that is after the start of the commit. (and of course: if it logs any warming stats -- you might have overlooked a cache) : Anyone have any idea what could be going on here? Ideally, <commit/> : would be an operation that blocks until the exact moment when the new : searcher is in place and is actually serving based on the new index that's how it works if you use waitSearcher=true ... are you sure you're not seeing the effects of some caching (HTTP?) in between solr and your client? did you try setting never304=true in the <httpCaching> section of solrconfig.xml ? -Hoss
