[SERVER-45058] currentOp "active" should go false when internal services block on condvars Created: 11/Dec/19 Updated: 29/Oct/23 Resolved: 23/Jan/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Internal Code |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eric Milkie | Assignee: | Amirsaman Memaripour |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | neweng, save-for-sam | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||
| Backwards Compatibility: | Minor Change | ||||
| Participants: | |||||
| Description |
|
Currently, the currentOp output sets "active" to true for a particular Op if the Op's Client has an associated OperationContext. With the introduction of the waitForConditionOrInterrupt family of functions, we now have several internal service threads that spend most of their lives blocked waiting for a condvar to be signaled – but to do so requires an OperationContext, so these threads show up as "active" in the currentOp output. This is confusing and makes the utility of the "active" field pretty useless. It would be better if we could fix this behavior so "active" is false for these threads if they are blocked. |
| Comments |
| Comment by Githook User [ 23/Jan/20 ] |
|
Author: {'email': 'amirsaman.memaripour@10gen.com', 'name': 'Amirsaman Memaripour'}Message: |
| Comment by Mira Carey [ 17/Dec/19 ] |
|
We have a thread idleness macro today for when threads are blocked, but we should ignore their stacks. We should look into whether that's a reasonable tool to judge whether to consider a client "active" |