Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.
LOL -----Original Message----- From: openldap-bugs-bounces+worganc=nortel.com@openldap.org [mailto:openldap-bugs-bounces+worganc=nortel.com@openldap.org] On Behalf Of jclarke@linagora.com Sent: Tuesday, February 17, 2009 3:05 PM To: openldap-its@openldap.org Subject: (ITS#5954) deleting one of several syncrepl consumers deletes thewrong one Full_Name: Jonathan Clarke Version: RE24 OS: CentOS URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch Submission from: (NULL) (213.41.243.192) Hi all, It seems that when adding syncrepl consumers to be->be_syncinfo, they are added in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete on cn=config from be->be_syncinfo, the nth entry in the list is removed, which is not the same one. To reproduce: 1) If we start with this in cn=config: > olcSyncRepl: {0}rid=001 > olcSyncRepl: {1}rid=002 The list order is (schematically): be->be_syncinfo = {rid=002, rid=001} 2) Add add a rid=003, we have in cn=config: olcSyncRepl: {0}rid=001 olcSyncRepl: {1}rid=002 olcSyncRepl: {2}rid=003 and the list is: be->be_syncinfo = {rid=003, rid=002, rid=001} 3) We attempt to delete rid=003: dn: ...,cn=config changeType: modify delete: olcSyncRepl olcSyncRepl: {2}rid=003 The list then contains, value number 2 having been deleted: be->be_syncinfo = {rid=003, rid=002} The above patch changes the order syncrepl info is inserted in the list. This corrects the problem, and I have not seen any other consequences (by running the test suite and browsing the code). Is this OK? My apologies if I have missed something big here.
changed notes changed state Open to Test moved from Incoming to Software Bugs
jclarke@linagora.com wrote: > Full_Name: Jonathan Clarke > Version: RE24 > OS: CentOS > URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch > Submission from: (NULL) (213.41.243.192) > > > Hi all, > > It seems that when adding syncrepl consumers to be->be_syncinfo, they are added > in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete > on cn=config from be->be_syncinfo, the nth entry in the list is removed, which > is not the same one. Thanks for the patch, fixed in HEAD. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
changed notes changed state Test to Release
hyc@symas.com wrote: > jclarke@linagora.com wrote: > >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: CentOS >> URL: http://milopita.phillipoux.net/jonathan-clarke-090217.patch >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi all, >> >> It seems that when adding syncrepl consumers to be->be_syncinfo, they are added >> in LIFO order. However, when deleting the nth syncrepl consumer via a ldapdelete >> on cn=config from be->be_syncinfo, the nth entry in the list is removed, which >> is not the same one. >> > > Thanks for the patch, fixed in HEAD. > This ITS' subject was rather vague. Just for reference, this problem only affected in-memory structures, not the actual data in cn=config. Always solved by restarting slapd, thus.
changed notes changed state Release to Closed
fixed in HEAD fixed in RE24