[
https://issues.apache.org/jira/browse/SOLR-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15232462#comment-15232462
]
Mark Miller commented on SOLR-7729:
-----------------------------------
The problem is that the client is not smart about this at all. If you start it
with a collection url and then choose a collection, the behavior is no good.
This is a common way to init SolrJ clients, so that API was not very well
thought out to begin with IMO.
> ConcurrentUpdateSolrClient ignoring the collection parameter in some methods
> ----------------------------------------------------------------------------
>
> Key: SOLR-7729
> URL: https://issues.apache.org/jira/browse/SOLR-7729
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 5.1
> Reporter: Jorge Luis Betancourt Gonzalez
> Assignee: Mark Miller
> Labels: client, solrj
> Attachments: SOLR-7729-ConcurrentUpdateSolrClient-collection.patch,
> SOLR-7729.patch
>
>
> Some of the methods in {{ConcurrentUpdateSolrClient}} accept an aditional
> {{collection}} parameter, some of this methods are: {{add(String collection,
> SolrInputDocument doc)}} and {{request(SolrRequest, String collection)}}.
> This collection parameter is being ignored in this cases but works for others
> like {{commit(String collection)}}.
> [~elyograg] noted that:
> {quote}
> Looking into how an update request actually gets added to the background
> queue in ConcurrentUpdateSolrClient, it appears that the "collection"
> information is ignored before the request is added to the queue.
> {quote}
> From the source, when a commit is issued or the
> {{UpdateParams.WAIT_SEARCHER}} is set in the request params the collection
> parameter is used, otherwise the request {{UpdateRequest req}} is queued
> without any regarding of the collection.
--
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
