[SOLR-8733] versions=true on Optimistic Concurrency updates doesn't work with in multi shard collections

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Assignee: Unassigned
• Reporter: Chris M. Hostetter
• Created: 24/Feb/16 22:24
• Updated: 23/Apr/20 07:13

Description

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...

$ 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]}

Multinode multi-shard example of current broken behavior...

$ 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]}

Issue Links

• incorporates: SOLR-10250 SolrCloudClient doesn't return 'adds' in Response when 'versions' is requested