lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <ser...@gmail.com>
Subject Thoughts on CMS and SMS
Date Thu, 27 May 2010 07:58:29 GMT
Hi

I've been thinking recently why are these two named like they are ... with a
MS we're basically asking two questions: (1) should it block other merges
from happening (or app thread from continuing) and (2) should it do its
merges concurrently?

SMS answers 'true' to (1) and 'false' to (2), while CMS answers the
opposite.

BUT, there's really no reason why these two are coupled. E.g. someone who
wants to block other merges from running, or hold the app thread until
merges are finished, does not necessarily want the merges to run in
sequence. Those are two different decisions. Even if you want to block the
application thread and other merges, you can still benefit form having the
merges run concurrently.

So, I was thinking that what we really want is a BlockingMS and
NonBlockingMS that can be used according to the answer you look for in (1),
and then we can have variants for both that execute the merges concurrently
or not. I think that serial merging should be supported w/ BlockingMS only,
but am interested in other opinions. One of the scenarios for serial merging
is if the application wants to ensure no additional threads are spawned
other than what it decided to spawn, and therefore it can only be used w/
the BlockingMS.Another scenario is to control IO, but in this case a
NonBlockingSerialMS may fit as well (depends if you think other merges may
start while this one is running).

In fact, w/o changing much, we can have CMS optionally block other merges /
app thread by waiting until all merges are finished. We may even stick w/
the current SMS/CMS names, just documenting that CMS can be used to block
threads, only merges will be done concurrently.

What do you think?

Shai

Mime
View raw message