luceneMatchVersion is something that cause differences. You may want to
try 6.3 version to be on same page as Amrit's code.
On Fri, Jul 21, 2017 at 6:08 PM, Hendrik Haddorp
wrote:
> Thanks for trying to reproduce my issue.
>
> I'm using a Solr Cloud, my collection was quite small, only a 50-500
Thanks for trying to reproduce my issue.
I'm using a Solr Cloud, my collection was quite small, only a 50-500
documents, with one shard and a replication factor of 3. I updated all
of the documents in one request. Beside that the flow is pretty much
like yours.
The goal of my code was to add
Hendrik,
Ran a little test on 6.3, with infinite atomic updates with optimistic
concurrency,
cannot *reproduce*:
List docs = new ArrayList<>();
> SolrInputDocument document = new SolrInputDocument();
> document.addField("id", String.valueOf(1));
> document.addField("external_version_field_s", Sys
Hi,
I can't find anything about this in the Solr logs. On the caller side I
have this:
Error from server at http://x_shard1_replica2: version conflict for
x expected=1573538179623944192 actual=1573546159565176832
org.apache.solr.client.solrj.impl.CloudSolrClient$RouteException: Error
f
Hendrik,
Can you list down the error snippet so that we can refer the code where
exactly that is happening.
Amrit Sarkar
Search Engineer
Lucidworks, Inc.
415-589-9269
www.lucidworks.com
Twitter http://twitter.com/lucidworks
LinkedIn: https://www.linkedin.com/in/sarkaramrit2
On Fri, Jul 21, 2017
Hi,
when I try to use an atomic update in conjunction with optimistic
concurrency Solr sometimes complains that the version I passed in does
not match. The version in my request however match to what is stored and
what the exception states as the actual version does not exist in the
collectio