Open hartfordfive opened 2 years ago
When the connection has been closed, the goroutines responsible for handling ingress and egress internally call conn.setClosing
. You can retrieve the state and check if the reader has been stopped by a closing connection by calling conn.IsClosing
:
https://github.com/go-ldap/ldap/blob/93825e993f83b8c52408a771725f683055361e61/v3/conn.go#L258-L261
However, this does not account to abrupt connection losses, there's no way to determine if a connection has been forcefully killed without trying to send anything over the wire or wait for TCP timeout to happen.
hi @cpuschma
Can we add some code to detect and automatically reconnect?
My case is, if openldap server was restarted, the connection established by go-ldap module will become useless and never reconnect, so all further ldap queries are failed. Restarting Go application fixes the issue but this is not idea at all.
I used Python + python-ldap module before, its ReconnectLDAPObject works well in such case: https://www.python-ldap.org/en/python-ldap-3.4.3/reference/ldap.html#ldap.ldapobject.ReconnectLDAPObject
@iredmail I recommend you try this library: https://github.com/eryajf/ldapool
hi @cpuschma
Can we add some code to detect and automatically reconnect?
My case is, if openldap server was restarted, the connection established by go-ldap module will become useless and never reconnect, so all further ldap queries are failed. Restarting Go application fixes the issue but this is not idea at all.
I used Python + python-ldap module before, its ReconnectLDAPObject works well in such case: https://www.python-ldap.org/en/python-ldap-3.4.3/reference/ldap.html#ldap.ldapobject.ReconnectLDAPObject
Hi,
for me this is not scope of the project. I have already told you above everything necessary to check if the connection was terminated. You only have to implement this check and establish a new connection in case of an error.
I have the opinion that the library should not take over the decision of the users or developers, but should provide the basic functionality for them. For the same reason, the library does not have its own function for connection pooling, for example, because there are different ways to implement this and we block the way for us and the users because of backward compatibility.
My personal opinion: if the feature is required by most users, then better implement it in the library directly to bring the usability to a higher level. Otherwise everyone uses this ldap library has to implement his own pool and auto reconnection, it's a waste of time.
I have a use-case where I'm opening a connection that may be long-lived without any activity for a given period of time. Unfortunately it seems that these connections become "stale" sometimes and need to be re-established. Is there a method I can used directly, prior to running the
ldap.NewSearchRequest
function (in the v3 package) to confirm if the connection is still active/healthy, and if not, re-connect?