Re: error handling in async functions

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 06:45 PM 4/10/00 +0300, Adrian Pavlykevych wrote:
>On Sun, Apr 09, 2000 at 09:36:47PM -0700, Kurt D. Zeilenga wrote:
>> At 11:36 PM 4/4/00 +0300, Adrian Pavlykevych wrote:
>> >Where I can find list of connection related errors reported by asynchronous
>> >ldap_search(), and which are handled by ldap_result()?
>> 
>> If ldap_search() returns an error, it's unlikely that the request
>> was sent to the server.  Hence, you'd likely not bother to call ldap_result()
>> for response.
>
>Yes, I'm perfectly aware of this, the question is, how I can distinguish ldap_search() failure due to server problems, from that generated because of some local error conditions (malloc() failure, encoding problem, etc.)?

In general, by the value of the returned result code.  Codes 80-91 (*)
are reserved for APIs (RFC 2251), other codes are reserved for protocol
results.  (* The current C API specifications violate this generating
result codes beyond the range of reserved for it.  This issue is being
addressed by the IETF).

However, many implementations (including OpenLDAP) do not adhere to
100% to this requirement.  A recent scan through the code found a number
of such cases.  These should be fixed but is currently deferred (awaiting
IETF work in this area).

>I don't wan't to perform bind/unbind on each request, because that inhibits me from using cache on the client side,  but in this case I have to decide whenever reconnecting is necessary/possible upon _every_ error returned by LDAP functions I call in the process.
>
>As last resort I'll read the source of all underlying functions to determine which error codes could be returned by ldap_search() and their meaning.

Bad idea.  Code changes.

>I was asking this question on the list just to be sure that I didn't miss some documentation or description, which could spare me from going through all source code.

OpenLDAP-devel: RFC 2251 + draft-ietf-ldapext-ldap-c-api-xx.txt
OpenLDAP 1.2: RFC 1777 + RFC 1823

RFCs are available from the RFC Editor: www.rfc-editor.org
I-D are available from the IETF: www.ietf.org

>The error codes in question are:
>LDAP_PROTOCOL_ERROR
>LDAP_BUSY
>LDAP_UNAVAILABLE
>LDAP_UNWILLING_TO_PERFORM
>LDAP_CONNECT_ERROR
>
>If someone would be willing to give short comments about conditions to which applies each of thoses error codes, I'd be very gratefull.

The first four are protocol result codes, please refer to RFC 2251.
RFC 2251 will likely be revised in this area before being progressed
to "Draft Standard" status.  See draft-just-ldapv3-rescodes-xx.txt.

The last one (LDAP_CONNECT_ERROR) is an API generated result code
indicating the API could not connect to the server.  Defined by
RFC 1823, I believe.

>> 
>> >I need to catch all possible server failures while operating  asyncronously -
>> >ldap_result() is in polling mode.
>> >
>> >I've read RFC1823, but it doesn't cover the topic which errors are reported on
>> >which stage folowing execution path:
>> >ldap_init()
>> >ldap_bind()
>> >ldap_search()
>> >while(ldap_result()) {
>> >        [ ... processing ... ]
>> >}
>> 
>> Since you're toying with devel codes, you should read the ldap-c-api
>> I-D in the docs/drafts directory.
>
>Unfortunately it doesn't contail information about subsets of error codes returned by each function.

Currently, the best thing to do is to assume that API only generate
81-97 (not 81-90) or use the async API (see below comment).  This is
a "perfect" solution, but it's about the only usable solution to date.

>> >Could someone tell, when connection errors could be reported (e.g. whenever
>> >socket operation errors will be reported by ldap_search() or ldap_result()?
>> 
>> You should avoid worrying about socket
>> errors and just deal with LDAP result codes.
>
>What I meant, was whenever it  is  ldap_search() that returns error upon failure to send query to the server, or ldap_result().

ldap_search(), as it part of the async API, only returns codes
generated by the API and these are indicative of some condition
detected by the API.  You should assume that any non-LDAP_SUCCESS
result code indicates that the API was not able to send the
message.

You can attempt to take corrective action depending upon the
result code returned.  However, as the API provides a high
level interface, it is often quite difficult (if not impossible)
to determine why a particular result code was returned.

>
>Thanks for your patience and will to help,
>
>-- 
>Adrian Pavlykevych 			email: 		<pam@polynet.lviv.ua>
>System Administrator			phone/fax:	+380 (322) 742041
>State University "Lvivska Polytechnica"
>
>