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

DialTLS occasionally either timeouts or fails with "connection reset by peer" #349

Open
EvgenyAGRO opened this issue Dec 13, 2021 · 2 comments

Comments

@EvgenyAGRO
Copy link

Once in a while the API call will fail with one of the following (hosts and ips redacted):
LDAP Result Code 200 "Network Error": dial tcp: lookup: read udp: i/o timeout
LDAP Result Code 200 "Network Error": read tcp: read: connection reset by peer

This happens occasionally, with most of the calls go through (99% of the time) and all of a sudden failing once.
Using go-ldap v3.0.2

For each incoming request a new connection is created using ldap.DialTLS, bind is called conn.Bind after the request has finished the connection is closed in defer.

Additional info:

  • LDAP AD user exists, DNS lookup to host works
  • No Loadbalancer/Firewall present
  • DefaultTimeout of 60 seconds is used (as specified by default)

Trying to figure out what could be the reason for these sporadic failures. Maybe too many connections? Should I cache created connections, is the mentioned usage pattern ok?

@cpuschma
Copy link
Member

cpuschma commented Dec 24, 2021

Do you properly close the connections after using it? The target host/server might refuse to open any additional connections if the others are still dangling. For me, I didn't experience this and in my use case, I've multiple firewalls in between and ~120 binds / second.

Maybe too many connections? Should I cache created connections, is the mentioned usage pattern ok?

I would recommend re-using already established connections. For me, it brought a massive perfomance gain. When you implement it, just make sure to occasionaly (or when trying to do any operation) check for faulty connections. They can be killed abruptly without any notification to the client / server and you might run in an error if a connection has been pooled for too long and the server dropped the it in the meantime.

@kishaningithub
Copy link

Experiencing the same with v3.4.6.. connection has been closed correctly after usage and this happens at random.

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

No branches or pull requests

3 participants