openldap-bugs October 2006

openldap-bugs@openldap.org

31 participants
137 discussions

(ITS#4719) Support for running slapadd/slapindex as a user
by quanah＠stanford.edu 24 Oct '06

24 Oct '06

Full_Name: Quanah Gibson-Mount Version: All OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) It would be nice if you could pass -u and -g options to run as another user/group so that on systems where OpenLDAP is running as another user or group, the files created by slapadd & slapindex have the correct ownerships (rather than root, for example).

1 0

Re: (ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by ando＠sys-net.it 24 Oct '06

24 Oct '06

damonmo(a)gmail.com wrote: > The option 'network-timeout' used to stablish a socket-level timeout on meta > backend is missing on slapd-meta man pages. > Fixed in HEAD/re23. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4718) Option 'network-timeout' missing from slapd-meta man pages
by damonmo＠gmail.com 24 Oct '06

24 Oct '06

Full_Name: Daniel Montero Motilla Version: 2.3.27 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.38.203.12) The option 'network-timeout' used to stablish a socket-level timeout on meta backend is missing on slapd-meta man pages.

1 0

Re: (ITS#4696) Assert core in connection.c
by quanah＠stanford.edu 23 Oct '06

23 Oct '06

--On Monday, October 23, 2006 7:13 PM +0000 richton(a)nbcs.rutgers.edu wrote: > I just got bit with this c_writewaiter assert. This is 2.3.27 with patch > for #4708 and #4695. See > https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for > *c (full backtrace included for good measure). I'll note an important difference between your hitting this issue and my hitting this issue. In my case: (a) I was using connection.c code from HEAD (b) c_writewaiter was zero, and not one. The issue in my case I believe was due to two things: (1) An optimization bug in gcc, because once I rebuilt with gcc 4.1.1, I never got this issue, and (2) A race condition that existed in the HEAD code, that was recently fixed. I no longer experience this problem with the updated HEAD code and gcc 4.1.1 as the compiler. I'd actually say that your report on this issue is a new ITS. ;) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4696) Assert core in connection.c
by Kurt＠OpenLDAP.org 23 Oct '06

23 Oct '06

At 12:13 PM 10/23/2006, richton(a)nbcs.rutgers.edu wrote: >I just got bit with this c_writewaiter assert. This is 2.3.27 with patch >for #4708 and #4695. See >https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for >*c (full backtrace included for good measure). Try 2.3.28.

1 0

Re: (ITS#4696) Assert core in connection.c
by richton＠nbcs.rutgers.edu 23 Oct '06

23 Oct '06

I just got bit with this c_writewaiter assert. This is 2.3.27 with patch for #4708 and #4695. See https://www.nbcs.rutgers.edu/~richton/richton-20061023-backtrace.txt for *c (full backtrace included for good measure).

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by Paolo.Rossi.con＠h3g.it 23 Oct '06

23 Oct '06

--Apple-Mail-2-751178356 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > Are you patched for ITS#4708 and ITS#4695? Those are my current > "don't try to syncrepl without it" for RE23... No, I was using 2.3.27 "pure" I'll give a try, THX > > Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you > use a session log? Maybe just post the relevant config entirely... Right, and sorry It is a syncrepl with RefresAndPersist, with "retry 600 +" The enviroment is the same of ITS#4702 with 1m entry DB Paolo --Apple-Mail-2-751178356 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 <HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; = -khtml-line-break: after-white-space; "><DIV><BLOCKQUOTE = type=3D"cite"></BLOCKQUOTE><BR><BLOCKQUOTE type=3D"cite"><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Are you patched for ITS#4708 and ITS#4695? Those are = my current "don't try to syncrepl without it" for = RE23...</DIV></BLOCKQUOTE><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>No, I was using 2.3.27 = "pure"=A0</DIV><DIV>I'll give a try, THX</DIV><BR><BLOCKQUOTE = type=3D"cite"><DIV style=3D"margin-top: 0px; margin-right: 0px; = margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><BR></DIV><DIV = style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px; ">Is this refreshAndPersist, or refreshOnly? = delta-syncrepl? Do you use a session log? Maybe just post the relevant = config entirely...</DIV> </BLOCKQUOTE></DIV><BR><DIV>Right, and = sorry</DIV><DIV><BR class=3D"khtml-block-placeholder"></DIV><DIV>It is a = syncrepl with RefresAndPersist, with "retry 600 +"</DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>The enviroment is the same = of ITS#4702 with 1m entry DB</DIV><DIV><SPAN class=3D"Apple-style-span" = style=3D"border-collapse: separate; border-spacing: 0px 0px; color: = rgb(0, 0, 0); font-family: Helvetica; font-size: 15px; font-style: = normal; font-variant: normal; font-weight: normal; letter-spacing: = normal; line-height: normal; text-align: auto; = -khtml-text-decorations-in-effect: none; text-indent: 0px; = -apple-text-size-adjust: auto; text-transform: none; orphans: 2; = white-space: normal; widows: 2; word-spacing: 0px; "><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV><BR = class=3D"khtml-block-placeholder"></DIV><DIV>Paolo=A0</DIV></SPAN></DIV><B= R></BODY></HTML>= --Apple-Mail-2-751178356--

1 0

Re: (ITS#4717) Efficient handling of response lists in C-API
by Kurt＠OpenLDAP.org 22 Oct '06

22 Oct '06

At 10:14 AM 10/22/2006, ando(a)sys-net.it wrote: >Full_Name: Pierangelo Masarati >Version: HEAD >OS: irrelevant >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (81.72.89.40) >Submitted by: ando > > >In proxies, we occasionally need to mark some response messages as "don't care". > This is slightly different than "abandon", in the sense that, for performance >and band occupation, an abandon would likely get too late to the remote server, >but if the response is not removed from the list that would grow and waste >resources. > >In realistic cases we profiled proxies that spend 50-60% of the CPU time running >the list of messages to check if any of them has been abandoned. > >The proposed fix consists in: > >- keeping abandoned msgid's sorted, so that a bisection algorithm can be used to >check if a msgid has been abandoned > >- add a ldap_int_abandon() call that marks a message as "abandoned" without >actually sending an "abandon" operation. This call is, by now, private >(ldap_int_) since its use in normal clients would make little sense. However, >whenever it does make sense, there's no objection in making the call public >(sort of ldap_abandon_mark()). I rather not name this "abandon" as it doesn't send an Abandon request. Maybe name this "discard" instead. E.g., ldap_int_discard(). >With this change, the overall CPU used to check response list in the very same >test cases dropped to less than 1%. > >p.

1 0

(ITS#4717) Efficient handling of response lists in C-API
by ando＠sys-net.it 22 Oct '06

22 Oct '06

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando In proxies, we occasionally need to mark some response messages as "don't care". This is slightly different than "abandon", in the sense that, for performance and band occupation, an abandon would likely get too late to the remote server, but if the response is not removed from the list that would grow and waste resources. In realistic cases we profiled proxies that spend 50-60% of the CPU time running the list of messages to check if any of them has been abandoned. The proposed fix consists in: - keeping abandoned msgid's sorted, so that a bisection algorithm can be used to check if a msgid has been abandoned - add a ldap_int_abandon() call that marks a message as "abandoned" without actually sending an "abandon" operation. This call is, by now, private (ldap_int_) since its use in normal clients would make little sense. However, whenever it does make sense, there's no objection in making the call public (sort of ldap_abandon_mark()). With this change, the overall CPU used to check response list in the very same test cases dropped to less than 1%. p.

1 0

Re: (ITS#4716) syncrepl - consumer missed some delete
by richton＠nbcs.rutgers.edu 20 Oct '06

20 Oct '06

Are you patched for ITS#4708 and ITS#4695? Those are my current "don't try to syncrepl without it" for RE23... Is this refreshAndPersist, or refreshOnly? delta-syncrepl? Do you use a session log? Maybe just post the relevant config entirely...

1 0

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2006