[Date Prev][Date Next]
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
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/