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 <dsmi...@apache.org> 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 <arnoldbron...@gmail.com> 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.
> >
>

Reply via email to