-
Type:
Bug
-
Resolution: Done
-
Priority:
Major - P3
-
Affects Version/s: 2.8.0-rc2
-
Component/s: Diagnostics
-
None
-
Fully Compatible
-
ALL
While polling db.currentOp(true), I observed entries that appear to contain a mismatched "ns" for the operation described.
For example:
{
"desc" : "conn8872",
"threadId" : "0x6fb70080",
"connectionId" : 8872,
"opid" : 1699027235,
"active" : true,
"secs_running" : 0,
"microsecs_running" : NumberLong(226281),
"op" : "query",
"ns" : "mmsdbpings.config.hostDelectedCache",
"query" : {
"findandmodify" : "tmp.alertJobs",
"query" : {
"_id" : ObjectId("548ef33de4b01c3152fca506"),
"hostsDispatched" : {
"$ne" : null
},
"lock" : null
},
"update" : {
"$set" : {
"lock" : ObjectId("548ef34de4b01733bdb6778d"),
"locked" : ISODate("2014-12-15T14:42:21.161Z")
}
}
},
"client" : "10.10.0.229:35216",
"numYields" : 0,
"locks" : {
"Global" : "w",
"Database" : "w",
"Collection" : "W"
},
"waitingForLock" : true,
"lockStats" : {
}
}
Note the "ns" : "mmsdbpings.config.hostDelectedCache" while the target collection of the findandmodify is "tmp.alertJobs". This findandmodify is a "known" operation for the application, however the actual namespace on which it's performed is "alerts.tmp.alertJobs" - a different database altogether from the indicated "mmsdbpings".
I also noticed apparent mismatches for "update" operations on a collection that I'm confident receives no update ops.