Sometimes we got the LDAPSearchException (resultCode=32 (no such object),after restart the ldapclient, it works again. In the Openldap log file found the following exception:
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 fd=51 ACCEPT from IP=21.72.214.186:61043 (IP=0.0.0.0:636)
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 fd=51 TLS established tls_ssf=256 ssf=256
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND dn="" method=163
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND authcid="cn=5xxxxxx3,ou=64xxxx00,o=xx,l=xxxx,c=de" authzid="cn=5xxsde3,ou=64xxxx00,o=xx,l=xxx,c=de"
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND dn="ou=5xxxxxx3,ou=sites,dc=xx,dc=xxx" mech=EXTERNAL sasl_ssf=0 ssf=256
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 RESULT tag=97 err=0 text=
.....
Oct 29 10:26:55 xxxxx slapd[4797]: conn=9082 fd=51 closed (connection lost)
i have found the following explains about the "connection lost" exception:
"Probably nothing is wrong. You just have a naughty client which terminates LDAP sessions by closing the connection, without bothering to send an Unbind request first. When that happens, all slapd can tell is that the connection got lost "
The ldap connection of the client is always existing, but the ldap session is interrupt by the ldapclient, if the client request the ldapsearch next time, no Bind called. on the openldap server log found the following:
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 fd=93 ACCEPT from IP=21.72.214.186:56348 (IP=0.0.0.0:636)
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 fd=93 TLS established tls_ssf=256 ssf=256
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SRCH base="xxxxxx"
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SRCH attr=cn
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SEARCH RESULT tag=101 err=32 nentries=0 text=
the question is that, how can i catch the "connection lost" exception and how to handle the exception, so that not to start ldapclient again.
Thanks very much
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If an LDAP connection is always existing but its ldap session is already lost, the connection is unauthenticated any more. How can i verify the ldapconnection is unusable any more?
Can i use the WhoAmIExtendedRequest to check the status of the authetication of the ldapconnection? I got the idea of your from the thread "LDAP Session managment".
Thank you in advance
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Under normal conditions, the LDAP SDK will not close a connection without first performing an unbind (and although I'm not really familiar with OpenLDAP's logging, I assume that an unbind request would get logged). Assuming that this isn't a case in which you have some network equipment that is breaking the connection, the primary reason that a connection might be closed without first performing an unbind is if some kind of unexpected error is encountered during processing.
If there is some kind of unexpected error, then the best way to identify it is to use the LDAP SDK's debugging framework, via the com.unboundid.util.Debug class. If you can call Debug.setEnabled(true), then the LDAP SDK should record debug messages using the Java logging framework (which by default will show up in standard error). If you can't change the code for your application, you can enable debugging by launching the JVM with "-Dcom.unboundid.ldap.sdk.debug.enabled=true".
But in general, a good way to improve your application's resilience to lost connections is to switch from using individual connections to connection pools. You can have a pool with a single connection if that's all you need, but using a connection pool instead of a single connection allows you to do things like automatically retry failed operations (or at least operations that fail in a manner that indicates that the connection may no longer be valid) on a newly-created connection. Look at the LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method for setting that up. And because connection pools implement the same methods for performing operations as indvidual connections, it's a relatively simple matter to update your code to use the a pool instead of an individual connection (e.g., LDAPConnectionPool.search will perform a search using a connection from the pool, with much better handling for failures).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank your for your reply, maybe, i could not explained very clearly. The instance of the ldapconnection is always existing, the ldapclient can send the request with the connection, but without performing a bind, the ldapserver returns the exception: "no such object", it is difficult to distinguish, there is not really the object with the DN or because of the authentification exception, the server refused the request. The ResultCode is 32, it does not belong to the unusable connection's code. with ConnectionPool, for this case, it will create a newly connection to retry the failed opertions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I understand you correctly, you're saying that the server returns a "no such object" result for a particular request on an unauthenticated connection, but a "success" result on an authenticated connection. If that's the case, then that doesn't indicate any problem at all with the quality or usability of the connection. The "no such object" response shouldn't cause the client to think that it has to close the connection because the connection can still be used.
If you're concerned about a failed authentication attempt (or possibly even a successful bind attempt that authenticates as someone without permission to do other operations that might be required) using a pooled connection causing additional failures when trying to use that connection again for subsequent operations in the pool, then you have a couple of options:
Use two connection pools: one for binds, and one for all other operations. This will prevent the bind operations from interfering with the authorization identity used for other operations.
Use LDAPConnectionPool.bindAndRevertAuthentication method instead of the LDAPConnectionPool.bind method. The bindAndRevertAuthentication method will process a bind operation with the settings that you requested, but then (regardless of the success or failure of that bind attempt) will perform a second bind to reauthenticate the connection as whoever the connection is normally supposed to be authenticated as.
The UnboundID Directory Server does provide a third option, which is a special control that can be included in a bind request in order to process the bind without actually changing the authentication identity of the connection, but as far as I know, no other directory server provides a similar feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sometimes we got the LDAPSearchException (resultCode=32 (no such object),after restart the ldapclient, it works again. In the Openldap log file found the following exception:
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 fd=51 ACCEPT from IP=21.72.214.186:61043 (IP=0.0.0.0:636)
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 fd=51 TLS established tls_ssf=256 ssf=256
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND dn="" method=163
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND authcid="cn=5xxxxxx3,ou=64xxxx00,o=xx,l=xxxx,c=de" authzid="cn=5xxsde3,ou=64xxxx00,o=xx,l=xxx,c=de"
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 BIND dn="ou=5xxxxxx3,ou=sites,dc=xx,dc=xxx" mech=EXTERNAL sasl_ssf=0 ssf=256
Oct 29 08:26:45 xxxxx slapd[4797]: conn=9082 op=0 RESULT tag=97 err=0 text=
.....
Oct 29 10:26:55 xxxxx slapd[4797]: conn=9082 fd=51 closed (connection lost)
i have found the following explains about the "connection lost" exception:
"Probably nothing is wrong. You just have a naughty client which terminates LDAP sessions by closing the connection, without bothering to send an Unbind request first. When that happens, all slapd can tell is that the connection got lost "
The ldap connection of the client is always existing, but the ldap session is interrupt by the ldapclient, if the client request the ldapsearch next time, no Bind called. on the openldap server log found the following:
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 fd=93 ACCEPT from IP=21.72.214.186:56348 (IP=0.0.0.0:636)
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 fd=93 TLS established tls_ssf=256 ssf=256
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SRCH base="xxxxxx"
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SRCH attr=cn
Oct 30 13:31:06 xxxxx slapd[8617]: conn=1314 op=0 SEARCH RESULT tag=101 err=32 nentries=0 text=
the question is that, how can i catch the "connection lost" exception and how to handle the exception, so that not to start ldapclient again.
Thanks very much
If an LDAP connection is always existing but its ldap session is already lost, the connection is unauthenticated any more. How can i verify the ldapconnection is unusable any more?
Can i use the WhoAmIExtendedRequest to check the status of the authetication of the ldapconnection? I got the idea of your from the thread "LDAP Session managment".
Thank you in advance
Under normal conditions, the LDAP SDK will not close a connection without first performing an unbind (and although I'm not really familiar with OpenLDAP's logging, I assume that an unbind request would get logged). Assuming that this isn't a case in which you have some network equipment that is breaking the connection, the primary reason that a connection might be closed without first performing an unbind is if some kind of unexpected error is encountered during processing.
If there is some kind of unexpected error, then the best way to identify it is to use the LDAP SDK's debugging framework, via the com.unboundid.util.Debug class. If you can call Debug.setEnabled(true), then the LDAP SDK should record debug messages using the Java logging framework (which by default will show up in standard error). If you can't change the code for your application, you can enable debugging by launching the JVM with "-Dcom.unboundid.ldap.sdk.debug.enabled=true".
But in general, a good way to improve your application's resilience to lost connections is to switch from using individual connections to connection pools. You can have a pool with a single connection if that's all you need, but using a connection pool instead of a single connection allows you to do things like automatically retry failed operations (or at least operations that fail in a manner that indicates that the connection may no longer be valid) on a newly-created connection. Look at the LDAPConnectionPool.setRetryFailedOperationsDueToInvalidConnections method for setting that up. And because connection pools implement the same methods for performing operations as indvidual connections, it's a relatively simple matter to update your code to use the a pool instead of an individual connection (e.g., LDAPConnectionPool.search will perform a search using a connection from the pool, with much better handling for failures).
Thank your for your reply, maybe, i could not explained very clearly. The instance of the ldapconnection is always existing, the ldapclient can send the request with the connection, but without performing a bind, the ldapserver returns the exception: "no such object", it is difficult to distinguish, there is not really the object with the DN or because of the authentification exception, the server refused the request. The ResultCode is 32, it does not belong to the unusable connection's code. with ConnectionPool, for this case, it will create a newly connection to retry the failed opertions?
If I understand you correctly, you're saying that the server returns a "no such object" result for a particular request on an unauthenticated connection, but a "success" result on an authenticated connection. If that's the case, then that doesn't indicate any problem at all with the quality or usability of the connection. The "no such object" response shouldn't cause the client to think that it has to close the connection because the connection can still be used.
If you're concerned about a failed authentication attempt (or possibly even a successful bind attempt that authenticates as someone without permission to do other operations that might be required) using a pooled connection causing additional failures when trying to use that connection again for subsequent operations in the pool, then you have a couple of options:
The UnboundID Directory Server does provide a third option, which is a special control that can be included in a bind request in order to process the bind without actually changing the authentication identity of the connection, but as far as I know, no other directory server provides a similar feature.