pitpalme@gmail.com wrote:

masarati@aero.polimi.it wrote:

...

pitpalme@gmail.com 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.