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