Full_Name: Paul Amaranth Version: 1.2.3 & 1.2.7 OS: Solaris 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (208.231.254.31) We have a product that uses OpenLDAP libraries to communicate with a remote LDAP server. When the client machine load spikes to 100%, the client program becomes blocked. After 30 minutes or so, it will unblock and regain normal behavior, but this is unacceptable for a server (the client is an authentication server). This is being built and executed on a Solaris 2.6 system. Attaching to the blocked process with gdb, I see the following: #0 0xef5391a4 in _write () from /usr/lib/libc.so.1 #1 0xef46645c in ber_flush (sb=0xbb7b0, ber=0x20a210, freeit=0) at io.c:318 #2 0xef462b08 in ldap_send_server_request (ld=0xbb7b0, ber=0x20a210, msgid=5266, parentreq=0x0, srvlist=0x0, lc=0xc0e68, bind=0) at request.c:255 #3 0xef4628f8 in ldap_send_initial_request (ld=0xbb7b0, msgtype=99, dn=0xc0e44 "o=Company Name,c=US", ber=0x20a210) at request.c:169 #4 0xef45f61c in ldap_search (ld=0xbb7b0, base=0xc0e44 "o=Company Name,c=US", scope=2, filter=0x1fce08 "uid=t020l", attrs=0x0, attrsonly=0) at search.c:79 This has happened with OpenLDAP 1.2.3 and 1.2.7. This has happened with versions configured without threads and using Solaris lwp. This has happened with versions compiled with gcc 2.8.1 and the egcs-1.1.2 release. If the library was compiled with gcc 2.8.1, it would block at a significantly lower CPU load, maybe 70% utilization. The later egcs release is more robust, but it will block if the CPU utilization maxes out. The point at which the CPU maxes out is about 15-20 LDAP queries/second, more or less. It always blocks at the same place. Anyone have _any_ ideas? We're a little frustrated by this and we have a rollout deadline coming up. Any help will be greatly appreciated.
changed notes moved from Incoming to Software Bugs
This error is apparently caused when there is more than one outstanding asynchronous request (bind or search) without calling ldap_result(). The documention should note that ldap_result() should be called immediately after every asynchronous call. > > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to openldap-its@OpenLDAP.org. Your report > has been placed into our Issue Tracking System and has been assigned > the tracking number ITS#338. > > One of support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > You may follow the progress of this message by loading the following > URL in a web browser: > > http://www.OpenLDAP.org/its/index.cgi?findid=338 > > Please remember to retain your issue tracking number (ITS#338) > on any further messages you send to us regarding this message. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the message. > > In our experience many people ask questions that have been asked > before. We recommend that you review our online FAQ > > http://www.OpenLDAP.org/faq/ > > and search archives of our many mailing lists (such as openldap-software > and openldap-bugs). > > http://www.OpenLDAP.org/lists/#archives > > -------------- > Copyright 1999 The OpenLDAP Foundation, All Rights Reserved. > -- Paul Amaranth | Rochester MI, USA Aurora Group, Inc. | Systems & Software paul@AuroraGrp.Com | Unix / Windows / NT
Note that the Async API is with respect to the protocol, not to I/O. At 07:29 PM 12/23/99 GMT, paul@AuroraGrp.Com wrote: >This error is apparently caused when there is more than one outstanding >asynchronous request (bind or search) without calling ldap_result(). The whole purpose of having an async API is to support multiple outstanding requests. ldap_result supports a variety of mechanism for polling (or waiting) for responses. Kurt
changed notes changed state Open to Closed
Believed to be user error