> If a client has thousands or more requests in flight at the same time, it has to
> look up the right request every time it receives a response. As the requests are
> tracked in a doubly-linked list, lookup tends to take O(n) steps whichever
> direction we take and things generally get out of hand from there on.
> The linked branch puts them into a TAvl for quicker lookup, with another commit
> to let people test as (t)avl code is part of liblutil at the moment.
Is it worth putting parts of liblutil into libldap or maybe letting
liblutil be dynamically linked so it can be used from there?
Are there other options on the table?
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
I noticed that OpenSSL 1.1 now has an explicit dependency on Pthreads. Which means that now
even our "non-threaded" libldap, when built with OpenSSL, must actually be linked with the
threads library. In this age of multicore processors, is it really important to have a single-threaded
LDAP library any more? Should we just make libldap_r become the standard library?
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
There have been some reports coming in to the ITS system that likely should
go into OpenLDAP 2.4.48/LMDB 0.9.23. These are:
ITS#8969 - Tweak to LMDB page splits (already committed to LMDB RE0.9)
ITS#8968 - ASYNC connect mode does not work on Solaris
ITS#8967 - back-mdb "unchecked" limits broken with particular search
scopes. Needs fix.
ITS#8957 - ASYNC TLS mode is broken
ITS#8963 - StartTLS failures with back-ldap due to bug in timeout
calculation. Needs fix.
ITS#8472 - only do index DB cleanup if DB is running (fix committed to
ITS#8952 - High CPU usage when idletime is < 4 (fix committed to master)
Any objections to me syncing these over into RE24?
Packaged, certified, and supported LDAP solutions powered by OpenLDAP: