[OPENDJ-5582] LdapClientSocket connection leaked when handshake fails Created: 15/Oct/18 Updated: 04/Jun/20 Resolved: 29/Oct/18
|Affects Version/s:||6.0.0, 5.5.0|
|Reporter:||C-Weng C||Assignee:||Yannick Lecaillez|
|Epic Link:||Bugs 6.5|
|Support Ticket IDs:|
When the DJ LoadBalancer implementation is used with the following with a pre-binded authentication user, there seems to be failure cases that lead to continuous connection leak.
When using the above with a wrong username/or password there is a background retry of these connections that causes leak
Run the attached testcase, but monitor the netstat or lsof to see that connection growth happens to DJ.
tested on DJ6. Tested on DJ6.5 (client libs) but no improvement
Use the attached testcase and monitoring the connection to DJ even after the connection is closed.
If there is no wrong password or if no newFailoverLoadBalancer is used this issue is not seen.
Side concerns: It has been reported that this is one of the cases of leakage but there seems to be reported that even there is no issue with password, it is felt that if there is some exceptions, it is possible that connection leakage happens (so hopefully the solution here will also fix other related causes).
|Comment by Matthew Swift [ 15/Oct/18 ]|
Thanks for the detailed report. Resource leaks are never a good idea, especially file-descriptors. I've triaged this bug for 6.5.
|Comment by Yannick Lecaillez [ 16/Oct/18 ]|
The leak happens each time an error occurs during connection handshake phase either in StartTLS (LDAP_CLIENT_SSL_USE_STARTTLS), Bind (LDAP_CLIENT_AUTHN_BIND_REQUEST*) or initial heartbeat (LDAP_CLIENT_HEARTBEAT_ENABLED).
|Comment by Chris Ridd [ 20/Mar/19 ]|
I've removed 4.0.0 (DJ 5.0.0) from the affected versions because the leaked class does not exist in that version, so this exact bug cannot affect 4.0.0.
|Comment by Petr Matej [X] (Inactive) [ 09/Jul/19 ]|
Verified on 6.5.0