For anyone interested I did work around this. The problem was that I wasn't warming the index enough. When I ran full queries against the new index being switched to everything runs smoothly when the indices are swapped now. There must be some lower level caches that need to be filled that I'm not aware of. The thread that I pointed at in the first post seems to suggest it's the caches in the Sort object.
One can recreate this by starting up a non-warmed lucene index and firing 20 - 30 concurrent queries at it. Mostly likely lucene will freeze on all the threads. Maybe all the threads at the start are building the same cache multiple times? -M On Jan 25, 2008 2:01 AM, Michael Stoppelman <[EMAIL PROTECTED]> wrote: > BTW, I'm using Lucene 2.2.0. > > -M > > p.s. Congrats on the 2.3.0 release! > > > On Jan 24, 2008 7:42 PM, Michael Stoppelman <[EMAIL PROTECTED] > wrote: > > > Hi all, > > > > I've been tracking down a problem happening in our production > > environment. When we switch an index after doing deletes & adds, running > > some searches, and finally changing the pointer > > from old index to new all the threads start stacking up all waiting on > > isDeleted(). The threads seem to finish, they just get really slow taking up > > to 30 - 60 seconds. > > > > The problem has been discussed here before in 2005: > > http://mail-archives.apache.org/mod_mbox/lucene-java-user/200510.mbox/[EMAIL > > PROTECTED] > > > > > > Does anyone have any suggestions on how to work around this? > > > > -M > > > > >
