Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-14427

Potential bug in optimistic concurrency with versions=true and failOnVersionConflicts=false

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Open
    • Major
    • Resolution: Unresolved
    • 8.4.1, 8.5.1
    • None
    • None

    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

      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:

      curl -X POST -H 'Content-Type: application/json' 'http://localhost:8983/solr/test/update?versions=true&failOnVersionConflicts=false' --data-binary '
      [ { "id" : "2", "attr": "val", },
        { "id" : "1", "attr": "val", "_version_": -1 } ]'

      Consistent response:

      {
        "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}}

       
      As per the documentation, 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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            ssd532 Sachin Divekar
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated: