By far, the bulk of the work was trying to un-entangle the solr.xml from CoreContainer, especially as far as the <core> tags were concerned and allow cores to come and go. No matter whether we decide on some other mechanism than solr.properties or not, altering how we do this should be much easier now.
The work for rapidly opening/closing (and lazily loading) cores was enhanced as part of this restructuring, if I were going to do it all over again I'd probably break it into smaller chunks. But even if we change course, the opening/closing stuff won't be affected so we're probably OK there. As far as nesting is concerned, it seems like we can emulate by multi-level properties if necessary, at least for simple structuring, you can see that a little in the page I started here: http://wiki.apache.org/solr/Core%20Discovery%20%284.3%20and%20beyond%29, I did a straight-forward mapping from <cores> to a bunch of properties like cores.hostPort cores.adminPath etc. Now, all I'm saying with that is that simple structure is still possible, I'm not particularly wedded to the idea. Consider Log4J properties. (OK, maybe that isn't a great example, I find it more than a little confusing, but...). But part of the motivation for this is moving to the SolrCloud way of doing things. The present setup has assumptions built into it from single-core-only days that make dynamic adjustments hard. Just one example: CoreContainer.load essentially assumed that it was the only thread operating when loading cores. To allow cores to come and go I had to do quite a bit of coordinating work. If we extend this to cores coming and going in response to load, or cores/collections being created on-the-fly etc. I'm not sure solr.xml is going to adapt whereas system properties are a more automation-friendly way of doing things. If we're going to eventually expand/contract/dynamically have nodes come and go we probably need to be able to, essentially, define all our properties at run-time rather than have a static, edit-by-hand configuration file. All that said, I'm open to whatever consensus we build. It'll about break my heart to _undo_ code, but I'll survive somehow, partially consoled by the fact that actually reading the solr.properties file wasn't much of the work <G>... Erick On Fri, Mar 15, 2013 at 9:08 AM, Erick Erickson <[email protected]>wrote: > Added some bits to CHANGES.txt for SOLR-4196.... > > > On Thu, Mar 14, 2013 at 10:01 PM, Erick Erickson > <[email protected]>wrote: > >> OK, I'll see what I can put in tomorrow. It won't be comprehensive, >> probably just refer to the Wiki page after a very brief explanation. >> >> >> On Thu, Mar 14, 2013 at 9:45 PM, Mark Miller <[email protected]>wrote: >> >>> Okay - leaving it out on purpose can get kind of confusing - someone >>> that wanted to look at the state of trunk right now might think, oh, only >>> bug fixes and very minor changes, but surprise, there is actually a major >>> structural change. >>> >>> I think we should try and keep CHANGES up to date with reality for our >>> 'trunk', '4x' users. >>> >>> - Mark >>> >>> On Mar 14, 2013, at 9:24 PM, Erick Erickson <[email protected]> >>> wrote: >>> >>> > bq: Is there any mention of this in CHANGES yet >>> > >>> > Nope, it's one of the JIRAs I've assigned to myself. SOLR-4542. I have >>> started a Wiki page here: >>> > >>> http://wiki.apache.org/solr/Core%20Discovery%20%284.3%20and%20beyond%29 >>> > >>> > linked to from here: >>> > http://wiki.apache.org/solr/CoreAdmin#Configuration >>> > >>> > But I've been waiting for the dust to settle before fleshing this out >>> much. Although the more exposure it gets, I suppose the more chance people >>> will have to comment on it. If we're agreed that solr.properties is the way >>> to go, then I'll put something in CHANGES Real Soon Now and perhaps let the >>> Wiki page evolve in fits and starts. >>> > >>> > >>> > >>> > On Thu, Mar 14, 2013 at 8:43 PM, Mark Miller <[email protected]> >>> wrote: >>> > Is there any mention of this in CHANGES yet erick? Was just browsing >>> for it… >>> > >>> > - Mark >>> > >>> > On Mar 14, 2013, at 6:37 PM, Jan Høydahl <[email protected]> >>> wrote: >>> > >>> > > solr.yml :-) >>> > > >>> > > -- >>> > > Jan Høydahl, search solution architect >>> > > Cominvent AS - www.cominvent.com >>> > > Solr Training - www.solrtraining.com >>> > > >>> > > 14. mars 2013 kl. 22:02 skrev Yonik Seeley <[email protected]>: >>> > > >>> > >> On Thu, Mar 14, 2013 at 3:46 PM, Robert Muir <[email protected]> >>> wrote: >>> > >>> It seems to me there are two changes involved: >>> > >>> 1. ability to auto-discover cores from the filesystem so you don't >>> > >>> need to explicitly list them >>> > >>> 2. changing .xml format to .properties >>> > >> >>> > >> These are indeed completely independent. >>> > >> My main concern/goal in this area has been #1. >>> > >> I assume #2 is just because developer tastes have been shifting away >>> > >> from XML, but like you I worry about what happens for config that >>> > >> needs more structure. >>> > >> >>> > >> -Yonik >>> > >> http://lucidworks.com >>> > >> >>> > >> >>> --------------------------------------------------------------------- >>> > >> 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] >>> > > >>> > >>> > >>> > --------------------------------------------------------------------- >>> > 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] >>> >>> >> >
