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

Optimistic concurrency issue for nested documents

Attach filesAttach ScreenshotAdd voteVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: update
    • Labels:
      None

      Description

      I am using Solr v7.7.1 in cloud mode. I was facing an issue related to optimistic concurrency:

      I have a nested document which can be updated concurrently multiple times before committing the updates hence using _version_ to enable optimistic concurrency. During the process of indexing, we fetch the document which we want to modify along with its _version_ , modify it and then send it to solr along with the same _version_. However, even when I am sure that there is no concurrent update for a particular document, the following error is still thrown:

      Caused by: org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException: Error from server at http://1.2.3.4:8983/solr/mcollection_shard1_replica_n2: version conflict for 1111 expected=1645085633861910528 actual=1645090791527284737
      

      Here is the explanation of why this might have happened:

      While indexing a document, when _version_ is mentioned, I believe the solr checks the version of the already existing latest document by doing a real-time get.

      Now if you have 2 nested documents where, in one document (doc1), parent has id="1111" and in other document(doc2), the child has id="1111", then it may be possible that solr might check version of doc2 when you intended to index doc1. This might be because solr still indexes all the documents in flat structure and doesn't consider parent-child relationship while doing real-time get.

      For a fix, I had to make the id of parent and child documents different from each other.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              vishalaksh Vishalaksh Aggarwal

              Dates

              • Created:
                Updated:

                Issue deployment