[email protected] wrote: > [email protected] wrote: > >> [email protected] wrote: >> >>> I do see attributes reflecting state after "modify" (which changes >>> "sn" attribute). >>> Where exactly should I expect to see a note about "glue state"? >>> Is output from "-d Any" helpful to figure what's going on (or wrong)? >> >> My understanding of your previous message was that you got a positive >> result from delete, but an "Already exists" from a subsequent add. > > That=92s korrekt. > >> I inferred that you checked about the existence of the object and =20 >> you got >> a negative result. > > In my current test scenario I do not check. > I assume a non-error on =84delete=93 in fact =84deletes=93, so I just = > check if =20 > response > code success (in Perl: '$res->code =3D=3D Net::LDAP::LDAP_SUCCESS=91). > >> Apparently, my guess was wrong. In that case, you probably hit >> ITS#6097 <http://www.openldap.org/its?findid=3D6097>. > > *hmmm* Good idea, thanks. > But after reading ITS description I don=92t think it=92s what troubles = > me. > We don=92t actually neither have =84multi master mode=93, but =84mirror = > mode=93 =20 > and writes are done only on exactly one server, so there should not be =20= > > a problem with second server producing a concurrent write/modify. > I=92d expect the delete to be correctly propagated, but I can=92t check = > it =20 > is is, simply because I have to little knowledge to read debug log =20 > correctly. > =97
Paste the debug log somewhere we can see it then. Might as well use debug level -1 while executing this sequence. And provide the debug output from both servers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
