This kind of seems like an XY problem. Why do you want to get to the other core? If you need to run the same query on multiple cores… you shouldn’t be thinking that way, think “collections” rather than cores. And you can use “collection aliasing” (see the Collections API CREATEALIAS command) to alias to multiple _collections_. The rest is automatic.
If that’s irrelevant, please tell us _why_ your custom code needs to access otherCore, maybe there’s something built in. It’s just that much of the time trying to force stand-alone logic on SolrCloud is making it harder than it needs to be. Best, Erick > On Jan 6, 2020, at 2:39 PM, Arnold Bronley <arnoldbron...@gmail.com> wrote: > > Hi, > > I have one custom Solr plugin that uses following logic to access some > other core present on the same Solr instance. > > request.getCore().getCoreContainer().getCore(otherCoreName) where request > is an object of type SolrQueryRequest > > This works fine in master-slave mode. > > Now if try to use the same logic in SolrCloud mode, it does not work > because what was the core name above is a collection name now and core > name is something like otherCoreName_shard1_replica_n1. There is also a > possibility that the the core might be sharded in SolrCloud mode and it > partially exists on two or more separate Solr instances. > > How would I change above logic for accessing other Solr core so that it > works in SolrCloud mode?