[SERVER-3989] Cannot suppress ClientCursor::yield "warnings" from logs Created: 01/Oct/11 Updated: 06/Oct/14 Resolved: 08/Jul/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency, Logging |
| Affects Version/s: | 2.0.0 |
| Fix Version/s: | 2.7.2 |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Brian Stolz | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 10 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
CentOS |
||
| Issue Links: |
|
||||||||||||||||
| Operating System: | Linux | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
We have loglevel set to 0 and quiet mode on, and our logs are still being filled with these "warnings", its filling up the disk rapidly warning: ClientCursor::yield can't unlock b/c of recursive lock ns We use db.eval specifically for the benefit that it locks the db, so my understanding is these warnings are totally normal because of that. db.runCommand( { "getParameter" : "*" } ) |
| Comments |
| Comment by Benety Goh [ 08/Jul/14 ] |
|
The class emitting these warnings was removed in https://github.com/mongodb/mongo/commit/b3e8e45ea6f346f804161e1fe4043ba3e5850ba8 |
| Comment by Rick Garcia [ 27/Jan/14 ] |
|
I have the same problem. My log level is set to 0, yet warnings for findandmodify are still getting logged: warning: ClientCursor::yield can't unlock b/c of recursive lock ns These log entries are generating 6GB+ daily log files and I don't have a very busy application, nor do I get alot of traffic. |
| Comment by Eliot Horowitz (Inactive) [ 11/Apr/12 ] |
|
If you're referring the warning about yielding with findAndModify, that is different than locking, so that is a warning that could cause serious performance problems. Please open a ticket so we can help diagnose the issue. |
| Comment by Joel Westberg [ 11/Apr/12 ] |
|
Affects Windows, OSX and other *nix environments as well. We have a similar problem where we are locking the db by application design using findAndModify, and it's very rapidly filling up disk with logs. |