[jira] [Commented] (SOLR-8733) versions=true on Optimistic Concurrency updates doesn't work with in multi shard collections
[
https://issues.apache.org/jira/browse/SOLR-8733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17090328#comment-17090328
]
Sachin Divekar commented on SOLR-8733:
--
Was it ever tested for sharded collection? The documentation of these flags
does not mention anything about this limitation.
> 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: Chris M. Hostetter
>Priority: Major
> 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
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
[jira] [Updated] (SOLR-14427) Potential bug in optimistic concurrency with versions=true and failOnVersionConflicts=false
[
https://issues.apache.org/jira/browse/SOLR-14427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sachin Divekar updated SOLR-14427:
--
Description:
Hi all,
I am facing an issue similar to SOLR-8733 and SOLR-7404
The behaviour of {{versions=true}} and \{{failOnVersionConflicts=false }}is not
matching with the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency]
I have tried it with Solr v8.4.1 and v8.5.1. In both cases, the cluster
consisted of three nodes and a collection with 3 shards and 2 replicas.
Following simple test case fails.
Collection "test" contains only two documents with ids "1" and "2"
+Update operation:+
{code:java}
curl -X POST -H 'Content-Type: application/json'
'http://localhost:8983/solr/test/update?versions=true=false'
--data-binary '
[ { "id" : "2", "attr": "val", },
{ "id" : "1", "attr": "val", "_version_": -1 } ]'{code}
+Consistent response:+
{code:java}
{
"adds":[
"2",0,
"1",0],
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException",
"error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException",
"root-error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException"],
"msg":"Async exception during distributed update: Error from server at
http://10.0.5.237:8983/solr/test_shard1_replica_n1/: null\n\n\n\nrequest:
http://10.0.5.237:8983/solr/test_shard1_replica_n1/\nRemote error message:
version conflict for 1 expected=-1 actual=1664690075695316992",
"code":409}}{code}
As per the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency],
it should have not included 1 in "adds" and should have returned a proper
version for 2.
I tried different updates using combinations of _version_ and document values
to generate conflicts. Every time the result is the same. There is no problem
with system resources. These servers are running only these Solr nodes and Solr
has been given a few GB of heap.
Are those issues SOLR-7404 and SOLR-8733 still unfixed? Unlike these issues, I
am not using the schema and config from example templates. These nodes are set
up by following Solr's production deployment document.
Update: it works correctly for single shard collections.
was:
Hi all,
I am facing an issue similar to SOLR-8733 and SOLR-7404
The behaviour of {{versions=true}} and \{{failOnVersionConflicts=false }}is not
matching with the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency]
I have tried it with Solr v8.4.1 and v8.5.1. In both cases, the cluster
consisted of three nodes and a collection with 3 shards and 2 replicas.
Following simple test case fails.
Collection "test" contains only two documents with ids "1" and "2"
+Update operation:+
{code:java}
curl -X POST -H 'Content-Type: application/json'
'http://localhost:8983/solr/test/update?versions=true=false'
--data-binary '
[ { "id" : "2", "attr": "val", },
{ "id" : "1", "attr": "val", "_version_": -1 } ]'{code}
+Consistent response:+
{code:java}
{
"adds":[
"2",0,
"1",0],
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException",
"error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException",
"root-error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException"],
"msg":"Async exception during distributed update: Error from server at
http://10.0.5.237:8983/solr/test_shard1_replica_n1/: null\n\n\n\nrequest:
http://10.0.5.237:8983/solr/test_shard1_replica_n1/\nRemote error message:
version conflict for 1 expected=-1 actual=1664690075695316992",
"code":409}}{code}
As per the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency],
it should have not included 1 in "adds" and should have returned a proper
version for 2.
I tried different updates using combinations of _version_ and document values
to generate conflicts. Every time the result is the same. There is no problem
with system resources. These servers are running only these Solr nodes and Solr
has been given a few GB of heap.
Are those issues SOLR-7404 and SOLR-8733 still unfixed? Unlike these issues, I
am not using the schema and config from example templates. These nodes are set
up by following Solr's production deployment document.
> Potential bug in optimistic concurrency with versions=true and
> failOnVersionConflicts=false
>
[jira] [Created] (SOLR-14427) Potential bug in optimistic concurrency with versions=true and failOnVersionConflicts=false
Sachin Divekar created SOLR-14427:
-
Summary: Potential bug in optimistic concurrency with
versions=true and failOnVersionConflicts=false
Key: SOLR-14427
URL: https://issues.apache.org/jira/browse/SOLR-14427
Project: Solr
Issue Type: Bug
Security Level: Public (Default Security Level. Issues are Public)
Components: SolrCloud, UpdateRequestProcessors
Affects Versions: 8.5.1, 8.4.1
Reporter: Sachin Divekar
Hi all,
I am facing an issue similar to SOLR-8733 and SOLR-7404
The behaviour of {{versions=true}} and \{{failOnVersionConflicts=false }}is not
matching with the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency]
I have tried it with Solr v8.4.1 and v8.5.1. In both cases, the cluster
consisted of three nodes and a collection with 3 shards and 2 replicas.
Following simple test case fails.
Collection "test" contains only two documents with ids "1" and "2"
+Update operation:+
{code:java}
curl -X POST -H 'Content-Type: application/json'
'http://localhost:8983/solr/test/update?versions=true=false'
--data-binary '
[ { "id" : "2", "attr": "val", },
{ "id" : "1", "attr": "val", "_version_": -1 } ]'{code}
+Consistent response:+
{code:java}
{
"adds":[
"2",0,
"1",0],
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException",
"error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException",
"root-error-class","org.apache.solr.update.processor.DistributedUpdateProcessor$DistributedUpdatesAsyncException"],
"msg":"Async exception during distributed update: Error from server at
http://10.0.5.237:8983/solr/test_shard1_replica_n1/: null\n\n\n\nrequest:
http://10.0.5.237:8983/solr/test_shard1_replica_n1/\nRemote error message:
version conflict for 1 expected=-1 actual=1664690075695316992",
"code":409}}{code}
As per the
[documentation|https://lucene.apache.org/solr/guide/8_5/updating-parts-of-documents.html#optimistic-concurrency],
it should have not included 1 in "adds" and should have returned a proper
version for 2.
I tried different updates using combinations of _version_ and document values
to generate conflicts. Every time the result is the same. There is no problem
with system resources. These servers are running only these Solr nodes and Solr
has been given a few GB of heap.
Are those issues SOLR-7404 and SOLR-8733 still unfixed? Unlike these issues, I
am not using the schema and config from example templates. These nodes are set
up by following Solr's production deployment document.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
