Full_Name: Hendrik Harms Version: 2.1.17 OS: solaris 5.8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.114.62.38) sometimes the slapd writes updates in the wrong order into the replog file. I detected the problem by tying to delete many entries with there children. ldapdelete -v -c -r \ -w "secret" \ -D "dc=mycompany, dc=de" \ -H "ldap://hostname:port" \ -f FileWithDNs2delete The FileWithDNs2delete contains nearly 6500 entries. Each entry has 10 children (average). Most of the entries are deleted successfully. Some entries are deleted only on the master. In that case I found in the <slave:port>.rej File the error "Operation not allowed on non-leaf". I tried it again with saving the replog file before starting the slurpd. There I found the delete statement for the elements which caused the error before the delete statement of one of its leafs. It looks like a racing condition somewhere in the slapd where the replog is written.
changed notes changed state Open to Suspended moved from Incoming to Software Bugs
moved from Software Bugs to Historical
The bug state switched over to "suspended, historical". Have I to wait for a stable 2.2.x Release or is it possible that syncrepl.c will be include in one of the next 2.1.x Releases? Regards, Hendrik -- Dipl.-Ing. Hendrik Harms Volkswagen AG
Suspend state means that we're waiting for someone, anyone, to produce a suitable patch fixing the problem. This and a number of slurpd reports are in the Historic bin as there seems to be more interest in the community resolve these problems by replacing slurpd with syncrepl than to actually fix all of slurpd's problems. I guess I could have just as well placed them in the Software Bugs bin, but that likely wouldn't change your situation... the bug would be still be in a suspended. As far as syncrepl goes, it's targeted for release in 2.2 (which is presently in alpha release). At 12:33 AM 6/13/2003, extern.hendrik.harms@volkswagen.de wrote: >The bug state switched over to "suspended, historical". > >Have I to wait for a stable 2.2.x Release or is it possible that syncrepl.c >will >be include in one of the next 2.1.x Releases? > >Regards, >Hendrik >-- >Dipl.-Ing. Hendrik Harms >Volkswagen AG
moved from Historical to Incoming
changed notes changed state Suspended to Closed
changed notes changed state Closed to Test moved from Incoming to Software Bugs
changed notes
There is a partial fix for this now in CVS HEAD. The replog entries are now timestamped according to when the operation began, instead of when the operation was logged. The entries are still written in an unpredictable order, but it is now feasible for the replog to be sorted into correct order. slurpd has been modified to attempt to sort its queue when it reads the replog. With this patch, if operations execute at close to the same time and are logged at close to the same time, slurpd will replicate them correctly. However, when the log is out of order, there is no check for missing operations in a sequence. An operation that is significantly delayed (due to database contention) may still be replicated out of order if it is not logged by the time slurpd reads the replog. I.e., if all changes have been written to the replog, then slurpd will send them all in correct order. If any changes are outstanding/missing when slurpd reads the log, then the order is not guaranteed. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
At 02:22 AM 12/24/2003, hyc@highlandsun.com wrote: >There is a partial fix for this now in CVS HEAD. The replog entries are now >timestamped according to when the operation began, instead of when the >operation was logged. The entries are still written in an unpredictable >order, but it is now feasible for the replog to be sorted into correct order. You assume the order in which they are stamped is the "correct" (commit) order. This is not true. It is still possible that an add stamped after another needs to be processed before that other. That is, now we have a race to commit instead of a race to log. This, however, may be a better race to have. >slurpd has been modified to attempt to sort its queue when it reads the >replog. With this patch, if operations execute at close to the same time and >are logged at close to the same time, slurpd will replicate them correctly. >However, when the log is out of order, there is no check for missing >operations in a sequence. An operation that is significantly delayed (due to >database contention) may still be replicated out of order if it is not logged >by the time slurpd reads the replog. I.e., if all changes have been written >to the replog, then slurpd will send them all in correct order. If any >changes are outstanding/missing when slurpd reads the log, then the order is >not guaranteed. > > -- Howard Chu > Chief Architect, Symas Corp. Director, Highland Sun > http://www.symas.com http://highlandsun.com/hyc > Symas: Premier OpenSource Development and Support
> -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Kurt@OpenLDAP.org > At 02:22 AM 12/24/2003, hyc@highlandsun.com wrote: > >There is a partial fix for this now in CVS HEAD. The replog > entries are now > >timestamped according to when the operation began, instead > of when the > >operation was logged. The entries are still written in an > unpredictable > >order, but it is now feasible for the replog to be sorted > into correct order. > You assume the order in which they are stamped is the "correct" > (commit) order. This is not true. It is still possible that > an add stamped after another needs to be processed before that > other. Perhaps the current patch sets the timestamp at the wrong point, but this possibility *can* be completely eliminated. We know that a single client issuing requests on a single session will have those requests decoded in order, and they will be queued to the thread pool in order, and they will begin execution in the same order. > That is, now we have a race to commit instead of a race to log. > This, however, may be a better race to have. If in your example, the second Add depends on the first because the second entry is a child of the first, then there is no race. If the first Add hasn't committed by the time the second Add has started, the second Add will fail because the parent entry doesn't exist. It's not possible for these two requests to both succeed out of order. Also, most clients submitting requests that depend on each other will run synchronously - i.e., they won't even submit the second request until they've received a result for the first one. It would be foolish to do otherwise, since a failure on the first request would preclude the second from having any chance of success. I note that when test008 is run with replication logging, the resulting replog with this patch is processed by slurpd without any rejects. Without this patch there are large numbers of rejects. > >slurpd has been modified to attempt to sort its queue when > it reads the > >replog. With this patch, if operations execute at close to > the same time and > >are logged at close to the same time, slurpd will replicate > them correctly. > >However, when the log is out of order, there is no check for missing > >operations in a sequence. An operation that is significantly > delayed (due to > >database contention) may still be replicated out of order if > it is not logged > >by the time slurpd reads the replog. I.e., if all changes > have been written > >to the replog, then slurpd will send them all in correct > order. If any > >changes are outstanding/missing when slurpd reads the log, > then the order is > >not guaranteed. > > > > -- Howard Chu > > Chief Architect, Symas Corp. Director, Highland Sun > > http://www.symas.com http://highlandsun.com/hyc > > Symas: Premier OpenSource Development and Support > > >
> -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of Kurt@OpenLDAP.org > You assume the order in which they are stamped is the "correct" > (commit) order. This is not true. It is still possible that > an add stamped after another needs to be processed before that > other. I found a better approach, it required no change at all to slurpd. By putting the invocation of replog() into a callback, the log is guaranteed to be written before the result is sent to the client. So a client using synchronous requests will never have its request sequence logged out of order. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support
changed state Test to Release
changed state Release to Closed
I am still very interested in the fix of ITS#2512. I've seen that the fix is not part of then 2.1.26 Release. :-( Is there a chance to add this fix in the next Release (2.1.27)? Could I take the openldap-2.1.26.tgz with upgrading the server/slapd/repl.c to revision 1.40.2.7, if I want to play with the fix or are there any other files needed to be upgraded for this fix? regards, Hendrik -- ---------------------------------------------------- Hendrik Harms TOJAQ Datentechnik GmbH for Volkswagen AG K-DOB-46 IS Purchasing
I have already backported the fix to release 2.1, if you check out the current REL_ENG_2_1 CVS branch you'll get it. It will be in 2.1.27. See the commit log http://www.openldap.org/lists/openldap-commit/200401/msg00195.html for a list of all the files affected by this patch. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support > -----Original Message----- > From: owner-openldap-bugs@OpenLDAP.org > [mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of > extern.hendrik.harms@volkswagen.de > Sent: Thursday, February 19, 2004 3:59 AM > To: openldap-its@OpenLDAP.org > Subject: Re: wrong order of entries in replog file (ITS#2512) > > > I am still very interested in the fix of ITS#2512. > I've seen that the fix is not part of then 2.1.26 Release. :-( > Is there a chance to add this fix in the next Release (2.1.27)? > > Could I take the openldap-2.1.26.tgz with upgrading the > server/slapd/repl.c > to revision 1.40.2.7, if I want to play with the fix or are > there any other > files needed to be upgraded for this fix? > > regards, > Hendrik > > -- > ---------------------------------------------------- > Hendrik Harms > TOJAQ Datentechnik GmbH > > for Volkswagen AG > K-DOB-46 IS Purchasing > > > >
moved from Software Bugs to Archive.Software Bugs
fixed in HEAD,2.2.4