Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Client behavior when server is down (0.6.1 and 0.7.0) #162

Closed
airandfingers opened this issue Jan 16, 2014 · 3 comments
Closed

Client behavior when server is down (0.6.1 and 0.7.0) #162

airandfingers opened this issue Jan 16, 2014 · 3 comments
Labels
Milestone

Comments

@airandfingers
Copy link

We're currently using ldapjs for our LDAP client, in secure mode:

ldap.createClient({
    url : 'ldaps://192.1.1.1'
    /* tls options if using ldaps */
    tlsOptions : { ... }, //key, cert, passphrase, rejectUnauthorized: false, NPNProtocols
    /* turn on connection pooling */
    maxConnections: 10,
    /* 2 minutes */
    maxIdleTime: 120000,
    /* 30 second health checks */
    checkInterval: 30000
});

When our client starts up, the first call it makes is client.search, passing a callback that takes err and res. If the server is down, this callback is being called twice, once with a "connect EHOSTUNREACH" err, and again with a "socket hang up" err.

I tried upgrading our ldapjs version to 0.7.0, but for that version we're seeing an even worse issue - the "connect EHOSTUNREACH" error is unhandled, so our entire app crashes.

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: connect EHOSTUNREACH
    at errnoException (net.js:901:11)
    at Object.afterConnect [as oncomplete] (net.js:892:19)

Is this normal ldapjs behavior, or are we using ldapjs in some non-standard way? All we want is to be able to handle errors like these, rather than working around double-callbacks or adding try-catch blocks around every client.search call.

@pfmooney
Copy link
Contributor

See if pfmooney/node-ldapjs@6b7906c helps at all.

(edit: amended commit)

@airandfingers
Copy link
Author

Yes, that worked. Thanks! Will this be in NPM soon, or should I use a cloned copy for now?

@pfmooney
Copy link
Contributor

I would use a cloned copy for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants