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?

Reply via email to