[DOCS-8938] findAndModify not captured by Profiler Created: 28/Sep/16 Updated: 30/Oct/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Server |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Emily Hall | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 1 year, 14 weeks, 2 days ago | ||||||||
| Epic Link: | DOCSP-1769 | ||||||||
| Description |
|
findAndModify operations which do not exceed the slowms threshold will always be absent from the system.profile collection. This is happening because FindAndModify::run() is failing to call CurOp::enter_inlock(). The enter_inlock is responsible for raising the profiling level associated with the operation, based on the database profiling level. Failing to call it means that the operation's profiling level is erroneously left as "0". |
| Comments |
| Comment by Education Bot [ 31/Oct/22 ] |
|
Hello! This ticket has been closed due to inactivity. If you believe this ticket is still important, please reopen it and leave a comment to explain why. Thank you! |
| Comment by David Storch [ 29/Sep/16 ] |
|
emily.hall, I don't think we need to do anything special to document this bug, especially since the only affected stable version is 3.2.0. Recommend closing this ticket as "Won't Fix". |