openldap-bugs

openldap-bugs@openldap.org

1 participants
20963 discussions

Re: (ITS#6625) draft-zeilenga-ldap-c-api-concurrency support
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Some issues with tests/progs/slapd-mtread.c: - snprintf format "%04.4d" is not standard. How about just "%04d"? - However, shouldn't 'me' be 'myidx' in those snprintfs and when computing 'thisconn = (me + j) % noconns;' ? - A thread ID can be a struct, in which case whoami() will fail. OpenLDAP (the TLS code) already fails in that case, but still, no need to add do that. Could pass 'myidx' around, or create a thread-local variable for it with ldap_pvt_thread_key_create(). - It says "initially developed by Kurt Spanier", shouldn't that be Doug Leavitt? - scripts/test060-mt-hot takes a long time and can generate 2G of logs. Maybe it should run with a lesser loglevel by default? Put : ${SLAPD_DEBUG=0x4100} -- by default, avoid 1.-2 gigabytes of logs before sourcing defines.sh. -- Hallvard

1 0

Re: (ITS#6715) Broken 'sortvals' for attr with 1 value
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Also attr_valfind() breaks with sortvals if #values = 0. Not sure if it can be called that way, but it doesn't hurt to handle it right. -- Hallvard

1 0

(ITS#6719) syncrepl_add_glue_ancestors() uninitialized return
by h.b.furuseth＠usit.uio.no 22 Nov '10

22 Nov '10

Full_Name: Hallvard B Furuseth Version: 2.4.23, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl_add_glue_ancestors() returns 'rc' uninitialized if the 'else' branch of 'if ( ndn.bv_len > be->be_nsuffix[0].bv_len )' is taken: Then the loop is not entered. This also means the 'else' branch is useless. Should it be doing something more? Found with gcc -O -Wuninitialized . 'make test' does not seem to enter the 'else'.

1 0

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by hyc＠symas.com 21 Nov '10

21 Nov '10

rein(a)OpenLDAP.org wrote: > On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote: >> New syncprov consumers connecting to a forwarding server and presenting an >> apperently up-to-date cookie will loose any mods that have already taken place >> on the forwarding server if it itself is refreshing from its provider. This >> should not be a problem if the forwarding server have a sufficiently large >> syncprov log, but a fix for servers without is coming. > The currently committed fix for this its leaves one problem open. If a > forwarding server restarts in the middle of the refresh phase, after > making some changes but before updating the csn, new consumers > connecting with an apparently up to date csn set after the server comes > up again will not know that the context is dirty and will loose these > changes. The same problem arise if the server restarts between the time > a locally initiated delete operation is performed in the database and > the accompanying csn set is saved. > > A fix could be to always assume the context is dirty after start up, and > thereby forcing all clients to undergo the refresh phase even if they > are in sync until some operation that updates the csn set is performed. > An unnecessary refresh is probably better than loosing changes.. I haven't had the opportunity to review these patches yet, but the bug description sounds a little flaky to me. The original design is this: when a consumer requests a refresh from the provider, the provider uses a snapshot of its current contextCSN. All changes from the consumer's cookie to this snapshot (inclusive) are sent to the consumer. Any changes currently in progress that have not yet been committed will be skipped until the next refresh. Nothing is lost, it's simply delayed, and that's in accordance with syncrepl's "eventual convergence" model. Likewise, the provider only updates its contextCSN when a change is fully committed. syncprov should NOT need to defer any consumer while it has outstanding mods. There is no reason that would be needed by the sync protocol. Servers only update their contextCSN after an entire refresh has completed. If a downstream consumer connects while a forwarder is still refreshing, the consumer should receive nothing. (Or, it should only receive the changes between its cookie and the server's committed contextCSN, if any.) You may very well have found bugs in the implementation, but it sounds to me like you've changed the overall behavior to something outside of the original design. -- -- 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

(ITS#6718) Send new-cookie messages to all consumers
by rein＠OpenLDAP.org 21 Nov '10

21 Nov '10

Full_Name: Rein Tollevik Version: CVS head OS: Irrelevant URL: Submission from: (NULL) (84.215.59.121) Submitted by: rein When syncprov updates its csn as a result of syncrepl updating its, syncprov currently sends NEW_COOKIE messages only to those consumers that replicate the entry where the csn is stored. It should be sent to all consumers. A fix is coming. -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6710) Mods already refreshed on a forwarding server is lost by its consumer
by rein＠OpenLDAP.org 21 Nov '10

21 Nov '10

On 11/15/10 16:39 , rein(a)OpenLDAP.org wrote: > New syncprov consumers connecting to a forwarding server and presenting an > apperently up-to-date cookie will loose any mods that have already taken place > on the forwarding server if it itself is refreshing from its provider. This > should not be a problem if the forwarding server have a sufficiently large > syncprov log, but a fix for servers without is coming. The currently committed fix for this its leaves one problem open. If a forwarding server restarts in the middle of the refresh phase, after making some changes but before updating the csn, new consumers connecting with an apparently up to date csn set after the server comes up again will not know that the context is dirty and will loose these changes. The same problem arise if the server restarts between the time a locally initiated delete operation is performed in the database and the accompanying csn set is saved. A fix could be to always assume the context is dirty after start up, and thereby forcing all clients to undergo the refresh phase even if they are in sync until some operation that updates the csn set is performed. An unnecessary refresh is probably better than loosing changes.. Rein

1 0

(ITS#6717) syncprov performs unnecessary presentations/refreshes.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) I have a multimaster setup, and some read-only slaves mirroring the data with syncrepl. In some circumstances, I've noticed that restarting a slave server leads to a full presentation, even though the masters have an adequately sized sessionlog. This makes refreshOnly synchronization prohibitively expensive. It appears that the problem is as follows: The syncprov overlay uses the minimum CSN from the client cookie to decide where to start synchronization, regardless of whether that CSN has changed relative to the same SID's CSN on the provider. For example: Provider state: CSN: <1 second ago>...#001#... CSN: <1 year ago>.....#002#... sessionlog mincsn: <1 hour ago>...#001#... Consumer state: CSN: <1 minute ago>...#001#... CSN: <1 year ago>.....#002#... <-- same as SID 2 CSN on provider The syncprov overly will take the mincsn from the consumer cookie (the <1 year ago> one above) and compare it to the sessionlog mincsn when deciding whether to do a full presentation. Since the SID 2 CSN hasn't changed in the above example, the consumer is up to date on changes recorded on SID 2, so the SID 1 CSN from the cookie should be used. To reproduce: * Set up slapd servers ID 1 and 2 as multimaster nodes, and a third slapd server replicating from server 1. * Insert one entry into server ID 2, and restart servers 1 and 2. * Insert entries into Server ID 1. * Perform enough modifications / deletions on Server ID 1 to cause entries to be purged from the sessionlog (see ITS #6716). * Wait for slave to catch up, then stop the slave. * Do any modification on Server ID 1 (only need to change the SID 1 contextCSN) * Restart slave. Server will present entries to the slave rather than replaying the session log.

1 0

(ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) On line 2875 of servers/slapd/overlays/syncprov.c (release 2.4.23), the sessionlog mincsn is initialized to a zero-length value. if ( !sl ) { sl = ch_malloc( sizeof( sessionlog ) + LDAP_PVT_CSNSTR_BUFSIZE ); sl->sl_mincsn.bv_val = (char *)(sl+1); sl->sl_mincsn.bv_len = 0; sl->sl_num = 0; sl->sl_head = sl->sl_tail = NULL; ldap_pvt_thread_mutex_init( &sl->sl_mutex ); si->si_logs = sl; } >From there, sl->sl_mincsn isn't touched until log entries are purged from the sessionlog on line 1522: while ( sl->sl_num > sl->sl_size ) { se = sl->sl_head; sl->sl_head = se->se_next; strcpy( sl->sl_mincsn.bv_val, se->se_csn.bv_val ); sl->sl_mincsn.bv_len = se->se_csn.bv_len; ch_free( se ); sl->sl_num--; } So, after the sessionlog has its first entry recorded and before it has its first entry received, sl->sl_mincsn is a zero-length value, which means the following comparison on line 2536: if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { do_present = 0; will evaluate to true in cases where it should not. A quick fix would be to compare directly against the CSN of the sessionlog's head: --- syncprov.c.orig 2010-11-17 14:07:26.000000000 -0600 +++ syncprov.c 2010-11-19 16:50:58.000000000 -0600 @@ -2533,7 +2533,7 @@ /* 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 ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_head->se_csn ) >= 0 ) { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );

1 0

Re: ITS#6713
by masarati＠aero.polimi.it 19 Nov '10

19 Nov '10

DevMan wrote: > Please let me know the upgradation procedure. <http://www.openldap.org/doc/admin24/install.html> In general, <http://www.openldap.org/doc/admin24/index.html> p.

1 0

Re: ITS#6713
by devman1624＠yahoo.com 19 Nov '10

19 Nov '10

Please let me know the upgradation procedure. Thx DevMan Sent from my iPhone On Nov 18, 2010, at 3:33 PM, Pierangelo Masarati <masarati(a)aero.polimi.it> w= rote: > Please note that the current release is 2.4.23; since 2.4.16 many issues h= ave been fixed. If the problem persists after upgrading, please make sure y= ou provide useful information, as illustrated here <http://www.openldap.org/= faq/data/cache/56.html> and in subordinate links. >=20 > p.

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