IIRC there was a deadlock issue if we make flush sync'd, because of the call to maybeMerge.
Ie doFlush is sync'd but we cannot sync around the call to maybeMerge since it invokes mergeScheduler.merge. I think it may be because CMS waits, if there are too many merges already running, and we don't want it to wait holding IW's monitor lock. Maybe try making it sync'd and see if any tests deadlock? Mike On Thu, Nov 4, 2010 at 1:54 PM, Jason Rutherglen <[email protected]> wrote: > I'm curious why the flush call in IW getReader isn't synced? The main > work of flush is synced, ie, the doFlush method. Then we're syncing > yet again to call applyDeletes, redundantly because deletes were > previously flushed in the flush call. I'm guessing we're trying to > gain some concurrency however given doFlush is synced, there probably > isn't much? Maybe we should simply flush inside the sync this block > in getReader? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
