So are you talking about backing all this out of 4x or just taking the properties bits out? Because backing this all out of the 4x code line will be...er...challenging, much more challenging than just yanking the properties file bits out, this latter is much easier whereas reverting will be a pain, I'll need some help there. I'm not really willing to re-do all of the bits around preventing loading/unloading core operations occurring at the same time from the ground up, it was too painful to do the first time. But this isn't really a problem I don't think, since that code is only relevant if you specify the lazy core loading options in your cores.
I don't quite get what you mean by solr.xml and solrconfig.xml being similar, just both being xml files? And are we talking a discovery/no discovery attribute in, say, the <cores> tag? Nor do I quite get the bits around threading. The stress code does test the threading I think. It also specifically does both properties and xml versions of solr.###, so it is part of our normal testing. Whether we can harden it enough for 4.3 is certainly a legitimate question. So are we reconsidering what I had a couple of months ago with pluggable core discovery? The default would be to do things as they're done now, we'd provide an implementation that walked the directory structure, and dropping in a different version that, say, queried ZK or a database would be pretty straight-forward. but if the solr.properties thing is to be killed, now is the time. On Mon, Mar 18, 2013 at 8:42 PM, Mark Miller <[email protected]> wrote: > I've been thinking about this in the background. I tossed out some of the > idea's that were implemented here, and I also thought a properties file > rather than xml might make the most sense for container config. After all, > 99% of the things you set will be simple key->value props that are > attributes of the cores tag. I thought, wouldn't that just be simple as a > properties file? Easy hand wavy thought at the time. > > I had forgotten that the shard handler configuration had crept into > solr.xml. That made me think, what else will come creeping this way? Other > solrconfig.xml stuff that doesn't belong per SolrCore. If my memory is > right, shard handler was in solrconfig.xml at one point - so was the config > for zookeeper in the very first integration attempt with Solr. > > Shouldn't the Container and SolrCore config mostly match? Wouldn't it be > funny if was one yaml and the other xml? One a flat structure and the other > nested? I think so. > > So I'm changing my mind on the properties files and favoring the use of > the current solr.xml. It's a really easy switch for current users, it's > consistent with what we have, and we can get 99% of the benefits of Erick's > work even retaining solr.xml. > > I also think solr.xml and solrconfig.xml should be as similar as they can > be. > > The real problem with solr.xml is still solved with Erick's work - the > fact that cores are define there and Solr has to try and update the config > file. The file is really not so bad once we remove that little ugly wart. > > I think there would be a few details to work out, but this path is very > appealing to me. > > I don't think we should hurry this stuff - there is still some thread > safety concerns I have, and I'm not sure it's gotten a lot of use since > it's not part of the example or general tests. This is very important stuff > IMO, and we want to get this change right, even if that means it doesn't > make 4.3. 5x was almost invented for baking this type of change :) > > The faster we can come to a consensus, the faster we can get started > baking things though. > > Anyone voting for the properties file? > > - Mark > > On Mar 14, 2013, at 3:46 PM, Robert Muir <[email protected]> wrote: > > > I'm late to the game here, so I apologize if a lot of this has already > > been discussed... > > > > I was looking recently and a little confused about the new .properties > > format, a few questions: > > * is the current plan to deprecate the solr.xml support in 4.x and drop > for 5.0? > > * is there a real advantage to the .properties format over the > > existing .xml? When debugging it seemed I was in unknown territory a > > little bit, and this sorta means going forward that everything in here > > is assumed to be flat: but it isnt really today, and what if more > > stuff needed to be added in the future that wasnt flat. For example > > the shard handler stuff has nested elements, but i kinda had to guess > > at how this mapped to .properties (since xml differentiates between > > attributes and elements, but its not so clear with .properties). > > > > 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 > > > > I guess just brainstorming, like what if we just kept the existing > > .xml format? we could add a new "autoDiscover=true" attribute to the > > cores element for people who don't want to list them explicitly. > > Additionally we could make the file optional (in case you have no need > > to configure anything in it). This might be less of an intrusive > > change for 4.x too, as its a less radical change, just a new attribute > > users can test if they want. Maybe we make it the default later in 5.x > > but in general the format would still be the same, and we wouldnt need > > the 2 different config implementations. > > > > --------------------------------------------------------------------- > > 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] > >
