MapReduce randomly failing on same DataSet

[Travis Smith]

I have a map-reduce function that runs 2-6x on a request. It will work great for a while, then fail with a 

(assertion: 'value has to be set'; assertionCode: '10210'; errmsg: 'db assertion failure'; ok: '0.0') once in a while. If that happens, refreshing the page and initiating the mapreduce queries again successfully runs with no change to the dataset. 

$ mongo --version
MongoDB shell version: 2.0.2

On Mac OS X Lion. Using Mongoid/Rubydriver (mongo 1.5.1, mongoid 2.3.4, ruby 1.9.2). http://pastebin.com/KhziVrCG is a successful MR query and an failed one in the same request; and again, refreshing will succeed. 

So what I would really like is some thoughts on how to move forward with tracking this down. First, just as a review of the code I thought maybe dividing by zero on the last couple of lines of the reduce was doing it, but the message doesn't represent that nor does that behaviour match expected behaviour for divide by zero in js. Is there a way to grab or output data at a given state during a map reduce to see what's going on? 

Thanks for any direction on this. 

-Travis

 

[Scott Hernandez]

Is there anything in the server logs and what server version are you using?

> --
> You received this message because you are subscribed to the Google Groups
> "mongodb-user" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/mongodb-user/-/Ts0BpVk7vxYJ.
> To post to this group, send email to mongod...@googlegroups.com.
> To unsubscribe from this group, send email to
> mongodb-user...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/mongodb-user?hl=en.

[Travis Smith]

$ mongod --version
db version v2.0.2, pdfile version 4.5
Wed Feb  8 16:33:11 git version: 514b122d308928517f5841888ceaa4246a7f18e3

Wed Feb 8 15:08:36 [clientcursormon] mem (MB) res:15 virt:2630 mapped:80
Wed Feb 8 15:11:37 [clientcursormon] mem (MB) res:17 virt:2630 mapped:80
Wed Feb 8 15:16:37 [clientcursormon] mem (MB) res:17 virt:2630 mapped:80
Wed Feb 8 15:21:37 [clientcursormon] mem (MB) res:17 virt:2630 mapped:80
Wed Feb 8 15:26:37 [clientcursormon] mem (MB) res:17 virt:2630 mapped:80
Wed Feb 8 15:31:37 [clientcursormon] mem (MB) res:17 virt:2630 mapped:80
Wed Feb 8 15:32:55 [conn3] mr failed, removing collection :: caused
by :: 10210 value has to be set
Wed Feb 8 15:36:37 [clientcursormon] mem (MB) res:18 virt:2630 mapped:80
Wed Feb 8 15:39:26 [initandlisten] connection accepted from 127.0.0.1:57001 #4

I can see the failure in the output log. No additional information I
can glean from that one line.

-Travis

[Eliot Horowitz]

Seems to be a problem with stored js.
Can you send db.system.js.find() ?

[Travis Smith]

At first, I was trying to use stored js for the MapReduce. I figured
using MongoMigrations would make that easy, but I could never figure
out how to get the map reduce function see the stored js functions
right.

> db.system.js.find();
{ "_id" : "odd" }
{ "_id" : "food", "value" : function cf__1__f_() {
var value = {a:0, b:0};
var count = {a:0, b:0};
var min = {a:100, b:100};
var max = {a:-100, b:-100};
if (this.c == "a" || this.c == "b") {
value[this.c] = parseInt(this.value);
count[this.c]++;
min[this.c] = parseInt(this.value);
max[this.c] = parseInt(this.value);
emit(this.question_id, {count:count, values:value, min:min,
max:max, avg:{a:null, b:null}});
}
} }

I'm just going to dump these values and see if the map reduce
continues to generate an error. We're not using these currently.

-Travis

[Eliot Horowitz]

The problem is that "odd" doesn't have a "value" field.
You can either drop it or add a value.

[Travis Smith]

So after a day and half of dev we haven't seen this issue again, I'm
going to say that this solved it. Any indication as to why it would
not always fail or thoughts as to how I could identify this or a
similar issue faster in the future? Is part of the debugging process
always to check the stored js?

Thanks!

-Travis