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

["Yonik Seeley (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15905476#comment-15905476 ] 

Yonik Seeley commented on SOLR-8733:
------------------------------------

bq. the versions=true param is documented

interesting... 

FWIW, I implemented single-shard versions=true for internal testing needs a long time ago.  I specifically never documented it because it didn't have distributed / forwarding support and because I didn't know about the overhead / issues that support might commit us to.  I figured the question of if it *should* be a public API would be a future discussion.

> 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
>         Attachments: SOLR-8733_incomplete_test.patch, TestReturnedVersions.java
>
>
> 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.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org