Well, I think this JIRA will finally get some action...
The actual availability of any particular feature is best tracked by the actual JIRA ticket. The "fix version" is usually the earliest possible fix. Not until the resolution is something like "fixed" is the code really in the code line.
OK, I'm thinking along these lines. I've started implementation, but wanted to open up the discussion in case I'm going down the wrong path.
1> For installations with multiple thousands of cores, provision has to me made for some kind of administrative process, probably an RDBMS that really maintains this information.
So here's a brief outline of the approach I'm thinking about.
1> Add an additional optional parameter to the <cores> entry in solr.xml, LRUCacheSize=#. (what default?)
SOLR-1306, allow a data provider to be specified in solr.xml that gives back core descriptions, something like: <coreDescriptorProvider class="com.foo.FooDataProvider" [attr="val"]/> (don't quite know what attrs we want, if any).
3> Add two optional attributes to individual <core> entries
a> sticky="true|false". Default to true. Any cores marked with this would never be aged out, essentially treat them just as current.
b> loadOnStartup="true|false", default to true.
4> so the process of getting a core would be something like
a> check the normal list, just like now. If a core was found, return it.
b> Check the LRU list, if a core was found, return it.
c> ask the dataprovider (if defined) for the core descriptor. create the core and put it in the LRU list.
d> remove any core entries over the LRU limit. Any hints on the right cache to use? There's the Lucene LRUCache, ConcurrentLRUCache, the LRUHashMap in lucene that I can't find in any of the compiled jars....). I've got to close the core as it's removed.... It looks like I can use ConcurrentLRUCache and add a listener to close the core when it's removed from the list.
Processing-wise, in the usual case this would cost an extra check each time a core was fetched. If <a> above failed, we would have to see if the dataprovider was defined before returning null. I don't think that's onerous, the rest of the costs would only be incurred when a dataprovider did exist.
But one design decisions here is along these lines. What to do with persistence and stickiness? Specifically, if the coreDescriptorProvider gives us a core from, say, an RDBMS, should we allow that core to be persisted into the solr.xml file if they've set persist="true" in solr.xml? I'm thinking that we can make this all work with maximum flexibility if we allow the coreDataProvider to tell us whether we should persist any core currently loaded....
Anyway, I'll be fleshing this out over the next little while, anybody want to weigh in?