Lots of connections causes fatal error ERROR getaddrinfo ENOTFOUND graph.facebook.com graph.facebook.com:443

[leegee]

I have a lot of requests going on — is that what causes the following error?

    Error: getaddrinfo ENOTFOUND graph.facebook.com graph.facebook.com:443
    code: 'ENOTFOUND',
    errno: 'ENOTFOUND',
    syscall: 'getaddrinfo',
    hostname: 'graph.facebook.com',
    host: 'graph.facebook.com',
    port: 443

If this is indeed because of too many requests, what's the best way to limit them?

My code is a spider using Promises — so just limit the number of Promises executed...?

process.env.MAX_SOCKETS = 1 seems to have no effect.

[leegee]

at new FacebookApiException (/Users/lee/src/golem/node_modules/fb/lib/FacebookApiException.js:23:8)
at /Users/lee/src/golem/node_modules/fb/lib/fb.js:228:14
at Request._callback (/Users/lee/src/golem/node_modules/fb/lib/fb.js:436:12)
at self.callback (/Users/lee/src/golem/node_modules/fb/node_modules/request/request.js:187:22)
at emitOne (events.js:77:13)
at Request.emit (events.js:169:7)
at Request.onRequestError (/Users/lee/src/golem/node_modules/fb/node_modules/request/request.js:813:8)
at emitOne (events.js:77:13)
at ClientRequest.emit (events.js:169:7)
at TLSSocket.socketErrorListener (_http_client.js:267:9)
at emitOne (events.js:77:13)
at TLSSocket.emit (events.js:169:7)
at connectErrorNT (net.js:996:8)
at nextTickCallbackWith2Args (node.js:442:9)
at process._tickCallback (node.js:356:17)   at Post.<anonymous> in ../lib/Agent/Facebook/Post.js:65

[dantman]

There does appear to be an issue, at least on Ubuntu, where getaddrinfo will emit a ENOTFOUND under high load. https://github.com/nodejs/node-v0.x-archive/issues/7729

Generic rate limiting is your responsibility, see if you can find a good rate limiting package on npm.

Other suggestions have been to run dnsmasq to do local caching of dns.

[leegee]

Yes, I saw that node issue. I've been looking for a limiting package for an hour or so.... What I've seen requires replacing request, which is loaded by this module, so I'm not sure it's my responsibility — or can I do this without editing this module's source code?

I'm not sure dns caching is going to help if the problem relates to the number of file descriptors.

Thanks for at least letting me know I'm heading the right way!

[leegee]

I thought that if I required the request module prior to the fb module, I could use simple-rate-limiter to override the necessaries, but no... unless I'm brain dead for lack of sleep, which is possible.

This did work, though:

--- fb.js   2016-11-07 12:59:28.000000000 +0100
+++ fb-new.js   2016-11-07 12:59:18.000000000 +0100
@@ -37,7 +37,9 @@

 var _debug2 = _interopRequireDefault(_debug);

-var _request = require('request');
+// var _request = require('request');
+var limit = require("simple-rate-limiter");
+var _request = limit(require("request")).to(10).per(1000);

 var _request2 = _interopRequireDefault(_request);

[dantman]

You should not be rate limiting request, instead you should be rate limiting your FB.api calls at the application level.

The crudest way to simply rate limit all FB.api calls would be to wrap FB.api with your rate limiter.

var limit = require('simple-rate-limiter');
var fbApi = limit(FB.api.bind(FB)).to(10).per(1000);

// replace FB.api usage with fbApi

[leegee]

I don't think that that will work with Promises, I'll have to check.

[leegee]

Now Error: socket hang up code: 'ECONNRESET', but that's another issue... Thanks!

[ankitkhatri]

@leegee I was just wondering if you found a solution to this? I am still having this issue intermittently on FB.api calls and I am not sure this is related to Rate limiting because I only have like 5 users in the DB and I guess the app is making hardly 10 requests every hour at max. Can you help? Thanks