[SERVER-50882] Noisy log message, "Received interrupt request for unknown op" Created: 11/Sep/20 Updated: 29/Oct/23 Resolved: 03/Nov/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 4.9.0 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Drew Paroski |
| Resolution: | Fixed | Votes: | 3 |
| Labels: | neweng, qexec-team | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Sprint: | Query 2020-10-19, Query 2020-11-02, Query 2020-11-16 |
| Participants: |
| Description |
|
Log message 22790 appear a little while ago, and in a typical test it constitutes a large fraction of all log messages:
Can we lower this message's log level, or log it only occasionally, or reduce the frequency of the event it's logging about? |
| Comments |
| Comment by A. Jesse Jiryu Davis [ 06/Nov/20 ] |
|
I just wanted a large quantity of irrelevant messages about "Received interrupt request for unknown op" removed from BF logs. I still don't understand why they're constantly generated - is that symptomatic of an underlying bug? Why does the server receive incessant interrupt requests for unknown ops? Anyway, if we want to see log messages for cases where the op is known, then that message shouldn't have been demoted. But none of this is my code, it's up to the Query team. |
| Comment by Amirsaman Memaripour [ 06/Nov/20 ] |
|
I believe jesse is in the best position to answer the question, as he originally reported the issue. |
| Comment by Drew Paroski [ 06/Nov/20 ] |
|
kevin.pulo: I don't really have an opinion on the issue you raised - I'll defer to jesse and amirsaman.memaripour to answer your question about what the desired behavior should be. |
| Comment by Kevin Pulo [ 06/Nov/20 ] |
|
The original issue here was with the "Received interrupt request for unknown op" messages. I notice that, whilst the committed fix increases by 1 the debug output level required to get these messages, it also increased by 1 the debug level required to get the "Interrupting op" messages, ie. when the provided opId matches an in-progress operation, which is then killed. Is this intentional, and if so, what's the motivation? It seems to me that this may result in actual op kills no longer being logged in some test suites (ie. where they were previously), which could impact the diagnosis of BFs. My understanding is that the "Interrupting op" log messages aren't as voluminous as the "Received interrupt request for unknown op" ones, and so therefore aren't a problem. |
| Comment by Githook User [ 03/Nov/20 ] |
|
Author: {'name': 'Drew Paroski', 'email': 'drew.paroski@mongodb.com', 'username': 'paroski'}Message: |