|
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.
|