Skip to content

Conversation

@thesmart
Copy link

When piping a CursorStream, I get the following error after about 10K documents:

/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/server.js:484 throw err; ^ TypeError: Cannot read property 'info' of null at [object Object].<anonymous> (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/server.js:336:93) at [object Object].emit (events.js:67:17) at [object Object].<anonymous> (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:140:13) at [object Object].emit (events.js:70:17) at Socket.<anonymous> (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/connection.js:238:18) at Socket.emit (events.js:67:17) at TCP.onread (net.js:367:14) 

This is the offending block of code in server.js starting @ line 318:

 // Callback instance var callbackInfo = null; var dbInstanceObject = null; // Locate a callback instance and remove any additional ones for(var i = 0; i < server.dbInstances.length; i++) { var dbInstanceObjectTemp = server.dbInstances[i]; var hasHandler = dbInstanceObjectTemp._hasHandler(mongoReply.responseTo.toString()); // Assign the first one we find and remove any duplicate ones if(hasHandler && callbackInfo == null) { callbackInfo = dbInstanceObjectTemp._findHandler(mongoReply.responseTo.toString()); dbInstanceObject = dbInstanceObjectTemp; } else if(hasHandler) { dbInstanceObjectTemp._removeHandler(mongoReply.responseTo.toString()); } } // The command executed another request, log the handler again under that request id // HEY LOOK HERE ** HEY LOOK HERE ** HEY LOOK HERE ** HEY LOOK HERE ** if(mongoReply.requestId > 0 && mongoReply.cursorId.toString() != "0" && callbackInfo.info && callbackInfo.info.exhaust) { // HEY LOOK HERE ** HEY LOOK HERE ** HEY LOOK HERE ** HEY LOOK HERE ** dbInstance._reRegisterHandler(mongoReply.requestId, callbackInfo); } 

Notice that callbackInfo could be null.

@christkv
Copy link
Contributor

Can you provide failing test cases with the pull requests for proper
coverage
On Dec 15, 2012 11:11 AM, "John Smart" notifications@github.com wrote:

When piping a CursorStream, I get the following error after about 10K
documents:

/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/server.js:484
throw err;
^
TypeError: Cannot read property 'info' of null
at [object Object]. (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/server.js:336:93)
at [object Object].emit (events.js:67:17)
at [object Object]. (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:140:13)
at [object Object].emit (events.js:70:17)
at Socket. (/home/deploy/test/node-EmailBlast/node_modules/mongodb/lib/mongodb/connection/connection.js:238:18)
at Socket.emit (events.js:67:17)
at TCP.onread (net.js:367:14)

This is the offending block of code in server.js starting @ line 322:

 // Locate a callback instance and remove any additional ones for(var i = 0; i < server.dbInstances.length; i++) { var dbInstanceObjectTemp = server.dbInstances[i]; var hasHandler = dbInstanceObjectTemp._hasHandler(mongoReply.responseTo.toString()); // Assign the first one we find and remove any duplicate ones if(hasHandler && callbackInfo == null) { callbackInfo = dbInstanceObjectTemp._findHandler(mongoReply.responseTo.toString()); dbInstanceObject = dbInstanceObjectTemp; } else if(hasHandler) { dbInstanceObjectTemp._removeHandler(mongoReply.responseTo.toString()); } } // The command executed another request, log the handler again under that request id if(mongoReply.requestId > 0 && mongoReply.cursorId.toString() != "0" && callbackInfo.info && callbackInfo.info.exhaust) { dbInstance._reRegisterHandler(mongoReply.requestId, callbackInfo); } 

Notice that callbackInfo could be null.

You can merge this Pull Request by running:

git pull https://github.com/thesmart/node-mongodb-native callbackInfo.info

Or view, comment on, or merge it at:

#809
Commit Summary

  • Fixing fatal "Cannot read property 'info' of null"

File Changes

  • M lib/mongodb/connection/server.js (2)

Patch Links

@thesmart
Copy link
Author

Sorry I can't. Take a look at the 2nd comment block, I denoted the error. It's clearly a logical error, and I don't think a unit test is necessary for something that is logically verifiable as correct in theorm.

There is a pull request attached that adds the logical fix.

@christkv
Copy link
Contributor

Pull requests are only accepted with a testcase that reproduces the problem please see contributor guidelines

@christkv
Copy link
Contributor

I can't reproduce this one.

@advanced
Copy link

I just had the same problem, this pull request fixed the issue. I think it happens when there is some latency involved in my case 60ms ping and fails after 10k.
+1 for the merge

@christkv
Copy link
Contributor

@advanced can you reproduce it in code so I can try to figure out if we are just curing a symptom or if this is the only fix needed ?

@advanced
Copy link

something as simple as that might fail.

MongoClient.connect("mongodb://0.0.0.0/db", function(err, db) { if(err) { return console.dir(err); } var collection = db.collection('user'); var stream = collection.find().stream(); stream.on("data", function(data) { console.log(data._id) }); stream.on("end", function() { console.log('finished'); }); });

it never fails if I use my local mongodb server!

on a remote cluster it throws TypeError: Cannot read property 'info' of null after about 10k docs.
unfortunately it does not happen all the time. I tested 20 times and it happened about 4 times on a collection containing 4 million docs.

Checking if callbackInfo exist before checking callbackInfo.info makes sense to me , regardless of the possible underlying issue. it's better than throwing an exception.

the real issue is probably a network connection but that will need more digging.

@christkv
Copy link
Contributor

even with the fix does it keep delivering the data ?

@advanced
Copy link

it did hang on the second try

@christkv
Copy link
Contributor

yeah sound like a networking issue. most of these are usually badly configured firewalls (seems to be the norm rather than the exception, maybe firewall software just sucks). Merged into master

@christkv christkv closed this Dec 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

3 participants