[Date Prev][Date Next]
Re: (ITS#6368) Bug in deleting entry in MirrorMode
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6368) Bug in deleting entry in MirrorMode
- From: email@example.com
- Date: Fri, 13 Nov 2009 22:57:23 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> firstname.lastname@example.org wrote:
>> email@example.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
> 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 =
> 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
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
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/