Aaron Richton wrote:
So I'm seeing this new syncrepl_del_nonpresent trip on various modifications, and I'm seeing trouble on modifications that aren't the first one in a given connection. What next?2.3.20--I'm assuming syncrepl.c 1.250 ("filter2bv can't de-normalize UUIDs, must do it explicitly for back-ldap in test045")--appears to have fixed this. Thanks Howard (and really all of you, but Howard got that commit)! If anybody out there can spare a minute to clue me in on what was happening, what triggered it (why was I the only person seeing this?), what things to smell around if this regresses, or anything else that might be relevant, I'd really appreciate it. I'm amazed that I was closer than I'd expect (see my Jan 26 message that I wanted to Debug() the UUIDs) but at the same time I was grossly off (my buffer had syncprov.c, not syncrepl.c). Just trying to get some data so I might have some hope of not being grossly off next time...
Well, as the commit message said, I was chasing down a bug that test045 turned up in HEAD. The really strange thing is that a few weeks before, test045 was passing perfectly fine.
The problem was because UUIDs have two different formats - the "pretty" form is textual, the familiar hex-string notation, while the normalized form is binary. The syncrepl protocol transmits UUIDs in syncID sets in binary format, but we sometimes also need the textual form in search filters. (Which is a shame, because when evaluating filters, we only use the normalized form for indexing...) Basically the syncrepl consumer was searching for UUIDs but only providing the binary format, not the text format. It showed up repeatably in test045 which uses back-ldap, since back-ldap never uses the binary format.
-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/
