Full_Name: Rein Tollevik Version: CVS HEAD OS: irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein Syncrepl can update more than one csn value in one operation, but only one can be passed to syncprov in the csn queue. Syncprov should instead pick the updated values from the modify operation. A patch that fixes this is coming. This patch depends on the ITS#5972 patch, and is required for the new test058 to succeed. Rein Tollevik Basefarm AS
moved from Incoming to Software Bugs
changed notes changed state Open to Test
changed notes changed state Test to Release
rein@OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, but only one can > be passed to syncprov in the csn queue. Syncprov should instead pick the > updated values from the modify operation. The syncrepl patch broke the CSN queue, which has caused out-of-order updates in test050. I have reverted it. Every write operation begins with a queued CSN and ends by graduating a CSN. You removed the enqueueing step, and so the queue contents were invalid. > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. test058 has the same number of errors with or without the syncrepl patch, so I don't think it was relevant to the issues you were addressing. I'm still skeptical about the syncprov half of the patch. The two patches were actually unrelated, the syncprov patch takes effect regardless of the syncrepl patch. -- -- 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 Release to Test
rein@OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: CVS HEAD > OS: irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > Syncrepl can update more than one csn value in one operation, False. An operation can only affect one entry. An entry has only one CSN (entryCSN is single-valued). Multiple changes may have occurred to an entry before a consumer sees it, but the consumer will only see the final result and only the last entryCSN. On the other hand, multiple CSNs may have changed in the cookie that is transmitted to the consumer. That's a separate issue... > but only one can > be passed to syncprov in the csn queue. > Syncprov should instead pick the > updated values from the modify operation. > > A patch that fixes this is coming. This patch depends on the ITS#5972 patch, > and is required for the new test058 to succeed. > > Rein Tollevik > Basefarm AS > > -- -- 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 Open
hyc@symas.com wrote: > rein@OpenLDAP.org wrote: >> Syncrepl can update more than one csn value in one operation, but only one can >> be passed to syncprov in the csn queue. Syncprov should instead pick the >> updated values from the modify operation. > The syncrepl patch broke the CSN queue, which has caused out-of-order updates > in test050. I have reverted it. Every write operation begins with a queued CSN > and ends by graduating a CSN. You removed the enqueueing step, and so the > queue contents were invalid. I removed the queuing and graduating of the CSN syncrepl_updateCookie() would update, as that only sent one of the (possibly) many values that could be updated by that operation. With the syncprov half of the patch the queued patch should never be looked at, meaning that this queuing should be unnecessary here. The ordinary queue/graduation of the CSN received with an updated entry is still in place, and should continue to be so. >> A patch that fixes this is coming. This patch depends on the ITS#5972 patch, >> and is required for the new test058 to succeed. > > test058 has the same number of errors with or without the syncrepl patch, so I > don't think it was relevant to the issues you were addressing. It was only the syncprov half of ITS#5793 patch that was relevant for test058. The syncrepl half of the patch only removes code that should be unnecessary.. > I'm still skeptical about the syncprov half of the patch. The two patches were > actually unrelated, the syncprov patch takes effect regardless of the syncrepl > patch. Yes, the syncprov part of the patch doesn't need the syncrepl half, but I found it correct to clean up code that should be made unnecessary by that patch. All updates received during the persistent phase should include an updated CSN value, and should already have been transmitted to syncprov by the commit/graduate queue and have caused it to update its own csn set. I.e, the syncrepl_updateCookie() replace operation should only have caused syncprov to updated its cookie and thereby send NEW_COOKIE messages when syncrepl updated the CSN set at the end of the refresh phase. Apparently, there is something that causes this to break. More on that in another message on -devel. Rein
Removed from HEAD, broken