Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-18304

Duplicate "value" fields in the findAndModify command response

XMLWordPrintableJSON

    • Type: Icon: Bug Bug
    • Resolution: Done
    • Priority: Icon: Major - P3 Major - P3
    • 3.0.3
    • Affects Version/s: 3.0.2
    • Component/s: Concurrency, Querying
    • Labels:
      None
    • Fully Compatible
    • ALL
    • Hide

      my code involves quite a lot of details and it's c++; I'm still to build a simple test case in, for example, python

      In short:

      • one producer, running inserts like db.coll.insert ( {d: data, t: now()}

        ). Producer in a tight loop inserting 100K elements

      • 5-10 consumers, one in each thread, getting elements with
        db.coll.findAndModify({
        sort: { t: 1 }

        ,
        remove: true
        })

      consumers end up returning about 140-160K elements. Some are duplicated even thrice

      Show
      my code involves quite a lot of details and it's c++; I'm still to build a simple test case in, for example, python In short: one producer, running inserts like db.coll.insert ( {d: data, t: now()} ). Producer in a tight loop inserting 100K elements 5-10 consumers, one in each thread, getting elements with db.coll.findAndModify({ sort: { t: 1 } , remove: true }) consumers end up returning about 140-160K elements. Some are duplicated even thrice
    • Quint Iteration 3

      Issue Status as of Sep 29, 2015

      ISSUE SUMMARY
      On MongoDB instances running with document-level concurrency storage engines, concurrent modifications of the same document by multiple clients may cause WriteConflictExceptions to be thrown. These write conflicts are handled internally by retrying the operation.

      A bug that affects both findAndModify remove operations and findAndModify update operations with new=false may cause the "value" field to be included in the server's response multiple times. Each occurrence of the field is likely to be associated with different documents or different versions of the same document.

      The server's response was mutated to include the old version of the document prior to the delete or update operation taking place. If faced with a write conflict, the operation would be retried on a potentially different document. Each attempt to perform the operation would cause that document to be appended to the server's response under a new "value" field. This means that the last "value" field present in the server's response is the actual document that was updated or removed by the client.

      USER IMPACT
      How a driver handles duplicate fields in the server's response isn't standardized behavior. The most common scenarios are that:

      1. The driver may choose the first "value" field in the response. This corresponds to the document that was first attempted to be updated or deleted, but wasn't actually the one modified by this client.
      2. The driver may choose the last "value" field in the response. This corresponds to the document that was updated or deleted by this client.
      3. The driver may return an error because the "value" field was present in the response multiple times.

      For sufficiently large documents with many concurrent findAndModify operations, it is possible to trigger enough write conflicts such that the server's response exceeeds 16MB. This causes an error to be returned to the client saying that the BSONObj size is invalid.

      WORKAROUNDS
      None.

      AFFECTED VERSIONS
      The 3.0 release series up until (and including) 3.0.2 are affected by this issue. Only MongoDB instances running with document-level concurrency storage engines (e.g. WiredTiger and RocksDB) are affected. MMAPv1 doesn't have a notion of write conflicts and is not affected.

      FIX VERSION
      The fix is included in the 3.0.3 production release.

      Original description

      I'm using a mongo collection as a queue, on mongo v3.0.2 with wiredtiger; producers use simple inserts and consumers use findAndModify with a sort descending on a timestamp, and remove option

      I've noticed that when I use one producer and multiple consumers in separated threads, in quite a many cases more than one thread return or obtain the same element out of the findAndModify. I've reread the docs on the semantics, and this seems a bug to me

        1. findAndModify_remove_queue.js
          5 kB

            Assignee:
            max.hirschhorn@mongodb.com Max Hirschhorn
            Reporter:
            pep.martinez Pep Martinez
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: