On 6/28/2015 2:59 PM, Jorge Luis Betancourt González wrote:
> Yes CloudSolrClient is better suited for cloud environments, in this case I'm
> dealing with a single server with multiple collections. In the code I provide
> the ability to switch to CloudSolrClient instead of CUSC if a zookeper URL
Ups, sorry I forgot the issue URL:
https://issues.apache.org/jira/browse/SOLR-7729
- Original Message -
From: "Erick Erickson"
To: solr-user@lucene.apache.org
Sent: Saturday, June 27, 2015 11:33:53 AM
Subject: [MASSMAIL] Re: ConcurrentUpdateSolrClient ignoring the collection
d and non-cloud deployments.
Thanks for the replies,
Regards,
- Original Message -
From: "Erick Erickson"
To: solr-user@lucene.apache.org
Sent: Saturday, June 27, 2015 11:33:53 AM
Subject: [MASSMAIL] Re: ConcurrentUpdateSolrClient ignoring the collection
param in some
Jorge:
Another thing to consider: CloudSolrClient is a much better choice in cloud
environments that CUSC. What you're seeing isn't right, no doubt but using
the other class may:
1> not require a work-around
2> be much more efficient.
In a sharded situation, CloudSolrClient will route all the doc
Thanks for the prompt reply Shawn. I've created an issue about this [1] from
the code the collection parameter is clearly ignored unless is a commit or the
UpdateParams.WAIT_SEARCHER parameter is set in the params of the request, which
is an indication of a commit/optimize.
The queue only cont
On 6/26/2015 2:27 PM, Jorge Luis Betancourt González wrote:
> I'm trying to use the ConcurrentUpdateSolrClient class, that has some methods
> that accept and aditional parameter to indicate the collection, some of this
> methods are add(String collection, SolrInputDocument doc),
> request(SolrRe
