openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#8741) libldap ignoring timeout value
by Sean.Haugh＠vertivco.com 26 Sep '17

26 Sep '17

On Tue, Sep 26, 2017 at 06:06:23PM +0000, Hallvard Breien Furuseth wrote: > Try again without the "_" after "LDAP", like the ldap.conf manpage says. > That's unintuitive, but rather late to change at this point. This is using the LDAP C API. I have also used ldap_get_option calls to verify that the values are set correctly.=

1 0

Re: (ITS#8741) libldap ignoring timeout value
by h.b.furuseth＠usit.uio.no 26 Sep '17

26 Sep '17

On 26. sep. 2017 19:54, sean.haugh(a)vertivco.com wrote: > I have tried setting the LDAP_OPT_TIMEOUT, LDAP_OPT_NETWORK_TIMEOUT, > LDAP_OPT_TIMELIMIT values with ldap_simple_bind_s, and the call returns after > ~65 seconds rather than the 10-20 seconds I expect. Try again without the "_" after "LDAP", like the ldap.conf manpage says. That's unintuitive, but rather late to change at this point. -- Hallvard

1 0

(ITS#8741) libldap ignoring timeout value
by sean.haugh＠vertivco.com 26 Sep '17

26 Sep '17

Full_Name: Sean Haugh Version: 2.4.42 OS: Linux URL: Submission from: (NULL) (143.166.81.254) I have tried setting the LDAP_OPT_TIMEOUT, LDAP_OPT_NETWORK_TIMEOUT, LDAP_OPT_TIMELIMIT values with ldap_simple_bind_s, and the call returns after ~65 seconds rather than the 10-20 seconds I expect. The same is seen with ldap_result and ldap_simple_bind--regardless of the value of `timeout` that is set, whether explicit or NULL, the call blocks for ~65 seconds.

1 0

(ITS#8740) libldap ignoring timeout value
by sean.haugh＠vertivco.com 26 Sep '17

26 Sep '17

1 0

Re: (ITS#8732) LDAP_CIRCLEQ improvements
by okuznik＠symas.com 26 Sep '17

26 Sep '17

On Tue, Sep 26, 2017 at 02:00:40PM +0100, Howard Chu wrote: > Nothing in this patch says "rotate" anywhere. Please add some more > descriptive comments describing the purpose of each new macro. A version with the circular queue description extended to cover the rotation macros is available here: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170926-LDAP_CIRCLEQ.patch --=20 Ond=C5=99ej Kuzn=C3=ADk Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by hyc＠symas.com 26 Sep '17

26 Sep '17

hyc(a)symas.com wrote: > ondra(a)mistotebe.net wrote: >>> IMO using recursive mutexes means your code is broken. We introduced these for >>> accesslog.c but in fact we could avoid them at zero cost. Also I don't see the >>> relevance of libevent to this discussion. We use our own event mechanism and >>> it is more efficient than libevent. >> >> libevent is a dependency for the load balancer that I intend to propose >> for integration into the project after all the relevant dependencies >> have come in. >> >> There is a new version of this patch that provides an implementation on >> each platform or defers to the existing one (as per each platform's >> documentation). Untested except on POSIX and most of them seem pretty >> arcane anyway. >> >> ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170918-ITS8638-libldap_r-re… >> > It looks like glibc still doesn't define PTHREAD_MUTEX_RECURSIVE by default, > it requires compiling with either -D_GNU_SOURCE or -D_XOPEN_SOURCE. The > feature itself appears to be part of UNIX98. It's likely that all pthread > implementations available today support it, but it still seems a bit iffy. > OK, I see that current glibc defaults to _POSIX_C_SOURCE=200809 which includes __XOPEN_2K8. All of this came later than our rmutex.c which was written in 2006, so that explains where the need arose from. We should be safe pushing this in, go ahead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8732) LDAP_CIRCLEQ improvements
by hyc＠symas.com 26 Sep '17

26 Sep '17

ondra(a)openldap.org wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170913-LDAP_CIRCLEQ.patch > Submission from: (NULL) (82.10.24.68) > > > The CIRCLEQ macros are incomplete and not very useful on their > own, but when providing a few more that allow rotating it, they > are. Patch to that effect is attached. > > They could probably be made a bit more efficient as well, though. Nothing in this patch says "rotate" anywhere. Please add some more descriptive comments describing the purpose of each new macro. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8661) Fix warnings issued by Autoconf 2.68+
by hyc＠symas.com 26 Sep '17

26 Sep '17

okuznik(a)symas.com wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170524-Fix-warnings-issued-… > Submission from: (NULL) (2a02:c7f:2247:ec00:a3e:8eff:fe52:dac5) > > > Running aclocal/autoconf is quite noisy. The attached patch against master > follows the recommendations by the autoconf project > https://autotools.io/forwardporting/autoconf.html > > Looks fine, go ahead and merge. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8638) Recursive mutex in libldap_r
by hyc＠symas.com 26 Sep '17

26 Sep '17

ondra(a)mistotebe.net wrote: >> IMO using recursive mutexes means your code is broken. We introduced these for >> accesslog.c but in fact we could avoid them at zero cost. Also I don't see the >> relevance of libevent to this discussion. We use our own event mechanism and >> it is more efficient than libevent. > > libevent is a dependency for the load balancer that I intend to propose > for integration into the project after all the relevant dependencies > have come in. > > There is a new version of this patch that provides an implementation on > each platform or defers to the existing one (as per each platform's > documentation). Untested except on POSIX and most of them seem pretty > arcane anyway. > > ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170918-ITS8638-libldap_r-re… > It looks like glibc still doesn't define PTHREAD_MUTEX_RECURSIVE by default, it requires compiling with either -D_GNU_SOURCE or -D_XOPEN_SOURCE. The feature itself appears to be part of UNIX98. It's likely that all pthread implementations available today support it, but it still seems a bit iffy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8612) lmdb build fails on illumos / solaris
by lorban＠bitronix.be 23 Sep '17

23 Sep '17

--001a113f4a9a1feda10559dd9d6c Content-Type: text/plain; charset="UTF-8" LGTM. Thanks for the fix! On Fri, Sep 22, 2017 at 10:56 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Monday, March 06, 2017 6:21 PM +0000 lorban(a)bitronix.be wrote: > > Full_Name: Ludovic Orban >> Version: >> OS: OmniOS r151020 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2a02:a03f:1cdc:c300:384b:af79:f57c:b134) >> > > Thanks for the report! I was able to reproduce this issue under Solaris > as well. > > My proprosed fix is in: > > <https://github.com/quanah/openldap-scratch/tree/its8612> > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --001a113f4a9a1feda10559dd9d6c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">LGTM. Thanks for the fix!</div><div class=3D"gmail_extra">= <div class=3D"gmail_quote">On Fri, Sep 22, 2017 at 10:56 PM, Quanah Gib= son-Mount <<a href=3D"mailto:quanah@symas.com" target= =3D"_blank">quanah(a)symas.com</a>> wrote: <blockquote class=3D"= gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-= left:1ex">--On Monday, March 06, 2017 6:21 PM +0000 <a href=3D"mailto:lorba= n(a)bitronix.be" target=3D"_blank">lorban(a)bitronix.be</a> wrote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Ludovic Orban Version: OS: OmniOS r151020 URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (2a02:a03f:1cdc:c300:384b:af79:f57c:b134) </blockquote> Thanks for the report!=C2=A0 I was able to reproduce this issue under Solar= is as well. My proprosed fix is in: <<a href=3D"https://github.com/quanah/openldap-scratch/tree/its8612" rel= =3D"noreferrer" target=3D"_blank">https://github.com/quanah/openldap-s= cratch/tree/its8612</a>> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">h= ttp://www.symas.com</a>> </blockquote></div> </div> --001a113f4a9a1feda10559dd9d6c--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs