[SERVER-18784] Errors during concurrent update/upsert on an existing document with a unique index Created: 01/Jun/15 Updated: 16/Oct/21 Resolved: 03/Aug/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Index Maintenance, Querying, Write Ops |
| Affects Version/s: | 2.6.3, 3.0.3 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | aaskar | Assignee: | Ramon Fernandez Marina |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Steps To Reproduce: | Tested using version 2.6.3 and 3.0.3.
Sample Output on the second run:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
Given a collection with a unique index and when running concurrent updates (3 threads) with upsert as true on a given existing document, 1 to 2 threads raise the following exception:
I would expect all of the three updates to succeed because the document I am trying to update already exists. Instead, it looks like it is trying to do an insert on few or all of the update requests and few fails due to the unique index. Repeating the same concurrent update on the document does not raise any exceptions. Also, using find() on a document to bring it to the working set, then running the concurrent updates on that document also runs as expected. |
| Comments |
| Comment by aaskar [ 03/Aug/15 ] |
|
Thanks Ramon. |
| Comment by Ramon Fernandez Marina [ 03/Aug/15 ] |
|
Hi aaskar; I was unable to reproduce the behavior you describe on my end. However we've found other cases of I'm going to close this ticket as a duplicate of Thanks, |
| Comment by aaskar [ 02/Jun/15 ] |
|
Ramon Fernandez, I have doubled checked again and yes, all 301 documents are in col1. Note that I only checked the content of the document for first 30 and did a count to see that there are 301 documents in the collections. Then I was successful in reproducing the behavior I have described. Note that the moment you list all 301 documents, you would not be able to reproduce the issue until the large number of writes to the other collection and restarting the database occur. It feels to me that when either the documents or the index are in part of the working set, things behave correctly. |
| Comment by Ramon Fernandez Marina [ 02/Jun/15 ] |
|
aaskar, I'm definitely unable to reproduce this behavior; this is what I did:
Can you please check that between your first and second runs all documents with doc_id from 0 to 300 are actually present in db.col1? I'm asking because there's a scenario that can account for the behavior you're seeing:
This behavior is described in |
| Comment by aaskar [ 02/Jun/15 ] |
|
Yes, the code is exactly the same that produced the output you see above on my machine. 3 threads is the original setup when I encountered this issue, but in the test code, I made it 8 and I write to col2 to simulate actions which seems to make it more likely to reproduce the issue. Once I run the test code a second time after restarting MongoDB and commenting out the single thread filling to col1, I get these errors consistently. I am not sure if it is related to disk speed or available RAM. I am not using SSD and I have 8 GB of RAM, but Mongo only takes few hundreds MBs of physical memory. Did you restart the DB and comment out that line of code, before trying again? If yes, I also suggest trying to increase the document size and number of documents inserted to col2. |
| Comment by Ramon Fernandez Marina [ 02/Jun/15 ] |
|
Thanks for your report aaskar. I tried reproducing this behavior in 2.6.9 and 3.0.3, but couldn't trigger the errors you describe. Are you sure the code above is the one triggering the problem? You mention 3 threads but the code above starts 8, and I also see col1 and col2 so I'm wondering if you have a slightly different version of this reproducer. |