On Wed, Aug 13, 2008 at 6:22 PM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > > 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.
There is a relationship of 1:n between a MultiCore and CoreDescriptor. CoreDescriptor holding a reference to MultiCore is holding a reference to the container like RequestHandlers/SolrIndexSearchers holding a reference to SolrCore > > -Grant -- --Noble Paul
