[SERVER-18304] Duplicate "value" fields in the findAndModify command response Created: 03/May/15 Updated: 05/Oct/15 Resolved: 04/May/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Querying |
| Affects Version/s: | 3.0.2 |
| Fix Version/s: | 3.0.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Pep Martinez | Assignee: | Max Hirschhorn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: | 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:
consumers end up returning about 140-160K elements. Some are duplicated even thrice |
||||||||||||||||
| Sprint: | Quint Iteration 3 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
| Comments |
| Comment by Githook User [ 04/May/15 ] |
|
Author: {u'username': u'visemet', u'name': u'Max Hirschhorn', u'email': u'max.hirschhorn@mongodb.com'}Message: |
| Comment by Githook User [ 04/May/15 ] |
|
Author: {u'username': u'visemet', u'name': u'Max Hirschhorn', u'email': u'max.hirschhorn@mongodb.com'}Message: Otherwise the response will contain the "value" field multiple times |
| Comment by Max Hirschhorn [ 04/May/15 ] |
|
I was able to reproduce this with an FSM workload (attached) that repeatedly removes documents from a collection using the findAndModify command. Note that a similar issue exists for updates with new=false. While prototyping the workload, I found that the collection was still empty at the end of the workload. That is to say, despite some threads claiming to have removed the same document and running for a fixed number of iterations, all documents had actually been removed. From reading through the CmdFindAndModify implementation in 3.0.2, I realized that we would have already filled in the values for the result object prior to calling deleteObjects(), which may trigger a WriteConflictException. By moving the _appendHelper() call to after the if (found) statement, I can no longer reproduce the issue. (Note that the actual fix will be slightly more involved because we'll need to store a copy of the removed document for mmapv1.) To summarize, each thread is still removing a distinct document, but the response that comes back from the server has the wrong value for what document was removed. |
| Comment by Pep Martinez [ 04/May/15 ] |
|
I've also noticed that v3-mmapv1 and v2.6 are not affected by this issue |
| Comment by Ramon Fernandez Marina [ 04/May/15 ] |
|
Thanks for the report pep.martinez, we're able to observe the behavior you describe and we're investigating. |