[ https://issues.apache.org/jira/browse/SOLR-7127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14330441#comment-14330441 ]
Alan Woodward commented on SOLR-7127: ------------------------------------- I'd missed get/setIdField(), which I guess is something that you might want to change (although that really ought to be part of the Router config, but hey - one issue at a time...) How about instead of returning a vanilla SolrClient, we return a CollectionSolrClient, which is an extension of CloudSolrClient with all the setters overridden to throw UnsupportedOperationException. That also makes it easier to track whether or not we should close resources, etc. > Add method to CloudSolrClient to create per-collection clients > -------------------------------------------------------------- > > Key: SOLR-7127 > URL: https://issues.apache.org/jira/browse/SOLR-7127 > Project: Solr > Issue Type: Improvement > Reporter: Alan Woodward > Assignee: Alan Woodward > Priority: Minor > Attachments: SOLR-7127.patch, SOLR-7127.patch > > > CloudSolrClient isn't thread-safe if you're making requests to multiple > collections, because defaultCollection is mutable. This can be a pain if > you're trying to index into multiple collections from a single queue of > documents. > This issue adds a .getCollectionClient(String) method to CloudSolrClient that > returns a child client directed at that collection. Under the hood it's > another CloudSolrClient sharing it's resources with the parent client, but > with a separate default collection set. The method returns a SolrClient, > however, so you can't then change the collection unless you explicitly cast > it. > Sort of related to what I wanted to do on SOLR-6894, but this is more > focussed. -- This message was sent by Atlassian JIRA (v6.3.4#6332) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org