On Aug 13, 2008, at 12:07 AM, Noble Paul നോബിള്
नोब्ळ् wrote:
On Tue, Aug 12, 2008 at 8:39 PM, Grant Ingersoll
<[EMAIL PROTECTED]> wrote:
So, even though this passed in terms of votes, I don't have a real
strong
sense that we are "there" yet.
I especially feel queasy about the multicore stuff and worry about
putting
that into stone, so to speak. I guess I don't get why a single
core is not
just multicore w/ one core. For back compatibility, if
multicore.xml is
not there, then we know to use a default one. We also have a single
CoreDescriptor to handle the single case, but the CoreDescriptor
constructor
takes in a Multicore, so we abuse that and pass in null. I'm not
sure why
a CoreDescriptor needs to have a ref. to the Multicore to begin
with. It
doesn't seem to be used internally.
* We need a reference to multicore in CoreDescriptor because that is a
simple way to get a reference to the multicore rather than doing a
MultiCore.getInstance() (SOLR-638)
That doesn't make it right. The name of the class implies it
describes the core, not the Multicore.
* The question of should the single core be a multicore w/ one core
has been debated over and over and somehow we have decided that this
is best compromise we can do for backward compatibility. A lot of
users do not care about multicore and still go with the plain vanilla
single core deployment.
I'll go review the archives, but it doesn't make sense to me. If
anything, the singleCoreDescriptor could just be injected into
Multicore in the case where it is the only core.
* A CoreDescriptor taking a null multicore instance is fine because
there is no multicore at all.
Then we should, at a minimum, add a no-arg constructor, or at least
document it can take null. Maybe then the name of the class is
wrong. Class names are meaningful. And the name CoreDescriptor
doesn't strike me as the place to hold Multicore. Overall, however,
this reeks of the bigger problem in that we treat 1 core as a special
case instead of it being Multicore with only a single core.
-Grant
