Hoss Man created SOLR-8733:
------------------------------
Summary: versions=true on Optimistic Concurrency updates doesn't
work with in multi shard collections
Key: SOLR-8733
URL: https://issues.apache.org/jira/browse/SOLR-8733
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Noticed this while working on SOLR-445...
the {{versions=true}} param is documented as an option that can be used when
doing updates if you care about opportunistic concurrency so that you know for
certain which {{_version_}} was associated with each update you send, w/o
needing to issue a subsequent {{/get}} request for the updated documents (which
might return some _newer_ version if another client did an update immediately
after you...
https://cwiki.apache.org/confluence/display/solr/Updating+Parts+of+Documents
Ironically, even though DistributedUpdateProcessor is where all of the
opportunistic concurrency code lives, and the logic for {{versions=true}} is
handled, it does nothing to ensure that the results are populated when requests
are forwarded to other leaders - instead, the code seems to just assume all
updates have their version assigned locally, so they wind up being "0" ...
Single node example of it working properly...
{noformat}
$ bin/solr -e techproducts -noprompt
...
$ curl -H 'Content-Type: application/json'
'http://localhost:8983/solr/techproducts/update?versions=true' --data-binary
'[{"id":"abc!111","foo_s":"one"}, {"id":"XYZ!222","foo_s":"two"}]'
{"responseHeader":{"status":0,"QTime":10},"adds":["abc!111",1527095970400043008,"XYZ!222",1527095970402140160]}
{noformat}
Multinode multi-shard example of current broken behavior...
{noformat}
$ bin/solr -e cloud -noprompt
...
$ curl -H 'Content-Type: application/json'
'http://localhost:8983/solr/gettingstarted/update?versions=true' --data-binary
'[{"id":"abc!111","foo_s":"one"}, {"id":"XYZ!222","foo_s":"two"}]'
{"responseHeader":{"status":0,"QTime":32},"adds":["abc!111",0,"XYZ!222",0]}
{noformat}
--
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
