bq: why do we want to unload a core?
Well, I know of at least one situation where people have implemented auto-scaling that can do things like:
> split an index in the background. More generally maintain indexes of size no larger than X. Then move one or more of the splits "someplace else".
> move a core's index to SSD while it's hot.
> re-partition user's data based on some heuristics without downtime.
> any situation where a core is manipulated outside Solr and still needs to service requests in the mean time.
So I do wonder if we can stand the question on its head. Rather than think of it as the transient cores being an afterthought, what if we move all core management to a plugin? NOTE: this is really fuzzy ATM, just askin'.
Then we wouldn't have the distinction in solr of "transient", "lazy loading", "regular" deeply embedded in the CoreContainer & etc. code. Even in the case where we open/close the heavyweight objects rather than load/unload cores, we still have to maintain lists of what cores have searchers already open and the like, similar to what happens in transient cores. Does it make any sense to think of moving all core management to a (suitably modified) transient core plugin? Then the default implementation we provide would just manage the heavyweight objects rather than load/unload cores and others could do as they wished.
Going forward, when everything is SolrCloud, there would be a degenerate case of leader-only collections that could essentially be treated as we do the current standalone code I'd guess.
bq: lazy cores itself is a vestige a of the old master-slave model
Not at all sure I agree. Even when SolrCloud rules the world, there'll always be edge cases where some organization pushes the limit. I don't want to keep Solr from evolving just to accommodate these edge cases, but I also don't want to prematurely decide for them that "we can do it better". 'cause we can't in situation N+1.
Oh, and let's keep a distinction between "lazy" and "transient" cores. "lazy" just means it isn't loaded until it's called for, it can be permanent after that. "transient" is the whole cache-and-load/unload-when-needed bit. Don't quite know how those will reconcile going forward, but the idea of opening/closing heavyweight objects is still "lazy" cores in some sense.