Details
-
Bug
-
Status: Closed
-
Critical - P2
-
Resolution: Works as Designed
-
2.4.10
-
None
-
ALL
-
Description
Because of a race condition in my code, I can delete a set of docs over which I am in the middle of running a map/reduce job (precise details below, I don't believe they are relevant). The map/reduce query is indexed.
My expectation is that the map/reduce job would just "ignore" records that were deleted.
Instead something odder seems to happen - the jobs last for way longer than they should and we see performance degradation
For example, here's a db.currentOp:
{
|
"opid" : "replica_set1:406504931",
|
"active" : true,
|
"secs_running" : 560,
|
"op" : "query",
|
"ns" : "doc_metadata.metadata",
|
"query" : {
|
"$msg" : "query not recording (too large)"
|
},
|
"client_s" : "10.10.90.42:41453",
|
"desc" : "conn881377",
|
"threadId" : "0x6790e940",
|
"connectionId" : 881377,
|
"locks" : {
|
"^doc_metadata" : "R"
|
},
|
"waitingForLock" : true,
|
"msg" : "m/r: (1/3) emit phase M/R: (1/3) Emit Progress: 2899/1 289900%",
|
"progress" : {
|
"done" : 2899,
|
"total" : 1
|
},
|
Check out the Emit Progress...
There were a few of these, they all ran for 20 minutes or so (the number of docs being deleted was small - in the few thousand range), before eventually cleaning themselves up.
Bonus worry: I have a similar case in which I run a map/reduce over the entire collection (several 10s of millions of documents), to which documents
are continually being added or removed - should I worry, or is this an edge case that happens when a high % of the query set is removed....
(Details:
Thread 1: 1a) update a bunch of docs to have field:DELETE_ME
Thread 1: 2a) run a map/reduce job to count some of their attributes prior to deletion
Thread 2: 1b) update a bunch more docs to have field:DELETE_ME
Thread 2: 2b) run a map/reduce job to count some of their attributes prior to deletion
Thread 1: 3a) Remove all docs with field:DELETE ME
Thread 2: 3b) Remove all docs with field:DELETE ME
)