Consider the case where legacy code calls SolrCore.getSolrCore() while
another thread is in the middle of executing the SolrCore constructor
(either directly, or because it called to getSolrCore()) ... won't it
have access to a "partially constructed" core before all of the
initialization is complete?
Yes, that could happen (Not 'off the shelf'). In SOLR-350, I *think* I
adressed this. The core registry is extracted from SolrCore and is
careful to only set the default core after it is constructed.
It seems like either...
1) getSolrCore() should also synchronize on SolrCore.class
This is the big thing I wanted to avoid.
...OR...
2) SolrCore(...) should not include the "instance = this" line, we put
the synchronization block back into getSolrCore() and make it the only
place instance is assigned ... change it's documentation to make it
clear that it generates a new "anonymouns" SolrCore the first time it's
called and allways returns that same SolrCore
I tried this originally, but it breaks all the tests -- the tests
require the last constructed core is returned form getSolrCore()
does that make sense?
The only quick fix is #1 -- should we do that now or wait till SOLR-350?
I'm inclined to wait and keep an eye on SOLR-350.
thoughts?
ryan
