CoreContainer has getLoadedCoreNames and getAllCoreNames methods so I
thought that I was all set but it wasn't working as expected.
I expected that getAllCoreNames would give all core names regardless of if
they are loaded or not but it was behaving just like getLoadedCoreNames
during the debugging process.
So, finally I ended up implementing it as follows:
CoreContainer coreContainer = req.getCore().getCoreContainer();
// Convert coreContainer.getSolrHome() to a Path object
Path solrHome = Paths.get(coreContainer.getSolrHome());
CorePropertiesLocator locator = new CorePropertiesLocator(solrHome);
List<CoreDescriptor> coreDescriptors = locator.discover
(coreContainer);
// get list of core names from coreDescriptors
Collection<String> cores = coreDescriptors.stream().map(cd -> cd.
getName()).collect(java.util.stream.Collectors.toList());
On Thu, Nov 17, 2022 at 3:58 PM David Smiley <[email protected]> wrote:
> I suppose not. The CoreContainer internally knows whether it has completed
> or not but I don't see that it's exposed. It seems easy to support such a
> feature.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Nov 16, 2022 at 2:02 PM gnandre <[email protected]> wrote:
>
> > /api/cores or /solr/admin/cores return very useful information about the
> > current status of all the cores for the solr instance against which they
> > are invoked.
> >
> > However, if Solr instance has just rebooted then these calls come back
> with
> > empty responses like below or contain only the cores loaded so far. Is
> > there a way to make them wait till all the cores are loaded?
> >
> > Empty Response:
> > { "responseHeader":{ "status":0, "QTime":150}, "initFailures":{},
> > "status":{}}
> >
> > Partial Response:
> > {
> > "responseHeader":{
> > "status":0,
> > "QTime":35},
> > "initFailures":{},
> > "status":{
> > "books":{
> > "name":"books",
> > "instanceDir":"/var/lib/solr/books",
> > "dataDir":"/var/lib/solr/books/data/",
> > "config":"solrconfig.xml",
> > "schema":"schema.xml",
> > "startTime":"2022-11-14T20:55:36.571Z",
> > "uptime":4286,
> > "index":{
> > "numDocs":0,
> > "maxDoc":0,
> > "deletedDocs":0,
> > "indexHeapUsageBytes":0,
> > "version":4748,
> > "segmentCount":0,
> > "current":true,
> > "hasDeletions":false,
> >
> >
> >
> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@
> > /var/lib/solr/books/data/index
> > lockFactory=org.apache.lucene.store.NativeFSLockFactory@7bae9d87;
> > maxCacheMB=48.0 maxMergeSizeMB=4.0)",
> > "segmentsFile":"segments_c1",
> > "segmentsFileSizeInBytes":119,
> > "userData":{
> > "commitCommandVer":"0",
> > "commitTimeMSec":"1658435977333"},
> > "lastModified":"2022-07-21T20:39:37.333Z",
> > "sizeInBytes":119,
> > "size":"119 bytes"}}}}
> >
> > Because the books core above is empty and a very simple core, it gets
> > loaded pretty fast compared to other data-heavy cores.
> > The Final response when all cores are loaded contains 19 such cores in my
> > case.
> >
>
