[SERVER-15998] Don't fall-through on WriteConflictExceptions in write command update Created: 06/Nov/14 Updated: 11/Jul/16 Resolved: 07/Nov/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Write Ops |
| Affects Version/s: | None |
| Fix Version/s: | 2.8.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Daniel Pasette (Inactive) | Assignee: | Greg Studer |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | python benchrun.py -f testcases/simple_update_mms.js -t 1 2 4 8 --nodyno --mongo-repo-path ../mongo/ |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
WriteConflictException was not being handled properly by the write command update executor. This caused them to erroneously appear to succeed. Original Description I spent a bit of time today narrowing it down and the issue happens between changeset c84d5ea and changeset 7f9e3f3 (FYI, c84d5ea is a parent of 7f9e3f3). The diff between these two changesets is very small and attached. Here is the page of commits from GitHub: Here are the results. I only show Update.MmsIncShallow1 although all show similar patterns.
|
| Comments |
| Comment by Greg Studer [ 10/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Opened one for you - | |||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 10/Nov/14 ] | |||||||||||||||||||||||||||||||
|
I've got a build with this fix now, will see if it happens again - if so I will open a new ticket (maybe I should any way?) | |||||||||||||||||||||||||||||||
| Comment by Greg Studer [ 10/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Not sure this is the same issue - this was a very specific problem where a write wouldn't get retried if there was a conflict (but would report success). Here it seems like logOp() doesn't expect WriteConflicts in some cases. Definitely an issue though, will ask repl team. | |||||||||||||||||||||||||||||||
| Comment by Asya Kamsky [ 10/Nov/14 ] | |||||||||||||||||||||||||||||||
|
I think I just ran into this one... I'm on up-to-date master and I have this which appears to be identical, on a single document update by _id:
| |||||||||||||||||||||||||||||||
| Comment by Githook User [ 07/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Author: {u'username': u'gregstuder', u'name': u'Greg Studer', u'email': u'greg@10gen.com'}Message: | |||||||||||||||||||||||||||||||
| Comment by Daniel Pasette (Inactive) [ 06/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Greg and I found where we're not handling the conflict correctly in writeCmd's | |||||||||||||||||||||||||||||||
| Comment by Daniel Pasette (Inactive) [ 06/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Thanks for that info. The crucial difference is the writeCmd.
| |||||||||||||||||||||||||||||||
| Comment by Susan LoVerso [ 06/Nov/14 ] | |||||||||||||||||||||||||||||||
|
I am using an AWS HDD system, m2.4xlarge. 8 cores. Linux (I also turned WT logging off only because that was the baseline I had from the previous week.) Not sure what the difference is. Both my good numbers and bad numbers are very consistent with each other for all changesets I tested.
My mongo-perf command is:
| |||||||||||||||||||||||||||||||
| Comment by Daniel Pasette (Inactive) [ 06/Nov/14 ] | |||||||||||||||||||||||||||||||
|
sue, I'm not able to reproduce this on an 8 core linux box. What OS are you using?
| |||||||||||||||||||||||||||||||
| Comment by Matt Kangas [ 06/Nov/14 ] | |||||||||||||||||||||||||||||||
|
Commit range noted above: https://github.com/wiredtiger/mongo/compare/c84d5ea...7f9e3f3 |