openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 09 Dec '10

09 Dec '10

I "rebased" the patch on top of a recent change: revision 1.24 date: 2010/12/06 10:31:59; author: hallvard; state: Exp; lines: +5 -17 ITS#6625 Remove some LDAP_R_COMPILEs The new patch is here: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

rein(a)OpenLDAP.org wrote: > On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >> I think the best (blind) fix consists in only performing that test if >> sl_mincsn is assigned a value; something like > > I'm looking at an extended fix. The problem with the current > implementation is that is assumes the entries arrives in CSN order, > which isn't necessarily true in a MMR configuration. > > My fix drops sl_mincsn, keeps the log queue in CSN order and compares > with the head entry. It also wipes the log if it receives any changes > without CSN (i.e during refresh). > > There might still be a theoretical problem there, if the sid of an entry > in the log is not in the set sent by the consumer. But since we know > they have the same number of CSNs this can only happen during initial > setup of a multi-master configuration. In which case the admins real > problem is that he didn't bring the servers online in a controlled order.. OK, I'm not looking at this any more. Thanks, p.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 09 Dec '10

09 Dec '10

On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: > I think the best (blind) fix consists in only performing that test if > sl_mincsn is assigned a value; something like I'm looking at an extended fix. The problem with the current implementation is that is assumes the entries arrives in CSN order, which isn't necessarily true in a MMR configuration. My fix drops sl_mincsn, keeps the log queue in CSN order and compares with the head entry. It also wipes the log if it receives any changes without CSN (i.e during refresh). There might still be a theoretical problem there, if the sid of an entry in the log is not in the set sent by the consumer. But since we know they have the same number of CSNs this can only happen during initial setup of a multi-master configuration. In which case the admins real problem is that he didn't bring the servers online in a controlled order.. Rein

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 09 Dec '10

09 Dec '10

On Thu, Dec 09, 2010 at 09:09:21AM +0100, Pierangelo Masarati wrote: > I think the best (blind) fix consists in only performing that test > if sl_mincsn is assigned a value; something like > > /* Are there any log entries, and is the consumer state > * present in the session log? > */ > - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, > &sl->sl_mincsn ) >= 0 ) { > + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && > + sl->sl_num > 0 && > + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) > + { > do_present = 0; > /* mutex is unlocked in playlog */ > syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); > > However I'd like to hear some other opinion. This fix would have the effect of treating the sessionlog as empty until it overflows, and will cause unnecessary refresh traffic. Other than the patch I suggested (using the list head's CSN value directly), I can think of two other approaches: 1) When adding an entry to the sessionlog, check if sl_mincsn is empty. If it is, update sl_mincsn to the new entry's CSN. 2) When initializing the sessionlog, set sl_mincsn to the maximum contextCSN value of the underlying database. #2 seems ideal from an efficiency standpoint, although it differs from the algorithm the current code appears to be intended to implement. -- Chris Mikkelson | Vampireware; n, a project capable of sucking the cmikk(a)qwest.net | lifeblood out of anyone unfortunate enough to be | assigned to it which never actually sees the light | of day, but nonetheless refuses to die. (tlode(a)nyx.net)

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by masarati＠aero.polimi.it 09 Dec '10

09 Dec '10

I think the best (blind) fix consists in only performing that test if sl_mincsn is assigned a value; something like /* Are there any log entries, and is the consumer state * present in the session log? */ - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { + if ( !BER_BVISEMPTY( &sl->sl_mincsn ) && + sl->sl_num > 0 && + ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) + { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids ); However I'd like to hear some other opinion. p.

1 0

(ITS#6741) x500UniqueIdentifier handling
by jgcardoso＠seguridata.com 08 Dec '10

08 Dec '10

Full_Name: Juan González Cardoso Version: 2.4.23 OS: Red Hat 5.5 EL URL: ftp://ftp.openldap.org/incoming/juan-gonzalez-101208.cer Submission from: (NULL) (201.148.141.170) Inserting userCertificate values containing x500UniqueIdentifier attribute at issuerNames fails. Some values even makes server to crash.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by masarati＠aero.polimi.it 08 Dec '10

08 Dec '10

> What's special about DN rewriting so it has a configure option > anyway? It doesn't disable building of libraries/librewrite. It used to, as far as I remember. I remember something about performing simple suffixmassage when librewrite is not built. In any case I agree that given the widespread usage of rewrite capabilities (authz regexp, for example) not building librewrite is somehow pointless. p.

1 0

Re: (ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

What's special about DN rewriting so it has a configure option anyway? It doesn't disable building of libraries/librewrite. -- Hallvard

1 0

(ITS#6740) syncrepl/--disable-rewrite dependency
by h.b.furuseth＠usit.uio.no 08 Dec '10

08 Dec '10

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard configure should mention syncrepl here: --enable-rewrite enable DN rewriting in back-ldap and rwm overlay test059-slave-config fails with --disable-rewrite. Testrun/test.out says parse_syncrepl_line: unable to parse "suffixmassage=cn=schema,cn=config,cn=slave"

1 0

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by doug.leavitt＠oracle.com 06 Dec '10

06 Dec '10

On 12/ 6/10 04:09 AM, h.b.furuseth(a)usit.uio.no wrote: > I've made two fixes (I hope) to the concurrency commit, please review: > > - In do_abandon(), protected ldap_free_connection() with > ld->ld_conn_mutex. The function would unlock it when it did not own > the mutex. > > However I do not know why the mutex was moved out of > ldap_free_connection(), so maybe something more needs to be done. > The abandon operation is now protected by it's own abandon mutex, not by the conn mutex. So do_abandon is not protecting the conn unless it is actually in use. ldap_free_connection reference counts the connection and only frees it if there are no other users of the connection. This is why ldap_free_connection requires protection. If there are multiple simultaneous threads using the connection some of which may have in flight operations, those threads are not interrupted by the abandon of another thread. Consider connection A with 3 threads performing searches. Thread 3 may abandon it's search but threads 1 and 2 may continue with their operations. Removing the protection around ldap_free_connection will disrupt the reference counting for the connection and cause potential connection leakage and/or disrupt other threads usage of the connection. Doug.

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