[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ITS #4365 revisited

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/