From pitpalme@gmail.com Thu Nov 12 18:30:51 2009
From: pitpalme@gmail.com
To: openldap-bugs@openldap.org
Subject: Re: (ITS#6368) Bug in deleting entry in MirrorMode
Date: Thu, 12 Nov 2009 18:30:50 +0000
Message-ID: <200911121830.nACIUoQi073212@boole.openldap.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============7621560756465997858=="

--===============7621560756465997858==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

--001636988beae98b80047830ba81
Content-Type: text/plain; charset=3Dwindows-1252
Content-Transfer-Encoding: quoted-printable

pitpalme(a)gmail.com wrote:

> masarati(a)aero.polimi.it wrote:
>
>  pitpalme(a)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=3D92s korrekt.
>
>
>  I inferred that you checked about the existence of the object and you go=3D
t
>> a negative result.
>>
>
> In my current test scenario I do not check.
> I assume a non-error on =3D84delete=3D93 in fact =3D84deletes=3D93, so I ju=
st che=3D
ck if
> response
> code success (in Perl: '$res->code =3D3D=3D3D Net::LDAP::LDAP_SUCCESS=3D91).
>
>
>  Apparently, my guess was wrong.  In that case, you probably hit
>> ITS#6097 <http://www.openldap.org/its?findid=3D3D6097>.
>>
>
> *hmmm* Good idea, thanks.
> But after reading ITS description I don=3D92t think it=3D92s  what troubles=
 m=3D
e.
> We don=3D92t actually neither have =3D84multi master mode=3D93, but =3D84mi=
rror m=3D
ode=3D93 and
> writes are done only on exactly one server, so there should not be a prob=3D
lem
> with second server producing a concurrent write/modify.
> I=3D92d expect the delete to be correctly propagated, but I can=3D92t check=
 i=3D
t is
> is, simply because I have to little knowledge to read debug log correctly=3D
.


Follow up:

I modified my test Perl script to do a 'ldapSearch' after deleting and it
returns zero as number of found entries.
Sadly I have no idea, how to emulate '-MM' when using 'Net::LDAP' and it's
search function, so I can't check for 'glue' entries this way.
--=3D20
Regards,
Peter

--001636988beae98b80047830ba81
Content-Type: text/html; charset=3Dwindows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D3D"gmail_quote"><span dir=3D3D"ltr"><a href=3D3D"mailto:pitpalme=
(a)gma=3D
il.com">pitpalme(a)gmail.com</a></span>=3DA0wrote:<br><blockquote class=3D3D"=
gmai=3D
l_quote" style=3D3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
=3D
:1ex;"><div class=3D3D"im">
<a href=3D3D"mailto:masarati(a)aero.polimi.it" target=3D3D"_blank">masarati(a=
)aero.=3D
polimi.it</a> wrote:<br>
<br>
</div><div class=3D3D"im"><blockquote class=3D3D"gmail_quote" style=3D3D"marg=
in:0=3D
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href=3D3D"mailto:pitpalme(a)gmail.com" target=3D3D"_blank">pitpalme(a)gmai=
l.com<=3D
/a> wrote:<br>
<br>
<blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:=
1p=3D
x #ccc solid;padding-left:1ex">
I do see attributes reflecting state after &quot;modify&quot; (which change=3D
s<br>
&quot;sn&quot; attribute).<br>
Where exactly should I expect to see a note about &quot;glue state&quot;?<b=3D
r>
Is output from &quot;-d Any&quot; helpful to figure what&#39;s going on (or=3D
 wrong)?<br>
</blockquote>
<br>
My understanding of your previous message was that you got a positive<br>
result from delete, but an &quot;Already exists&quot; from a subsequent add=3D
.<br>
</blockquote>
<br></div>
That=3D92s korrekt.<div class=3D3D"im"><br>
<br>
<blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:=
1p=3D
x #ccc solid;padding-left:1ex">
I inferred that you checked about the existence of the object and you got<b=3D
r>
a negative result.<br>
</blockquote>
<br></div>
In my current test scenario I do not check.<br>
I assume a non-error on =3D84delete=3D93 in fact =3D84deletes=3D93, so I just=
 check=3D
 if response<br>
code success (in Perl: &#39;$res-&gt;code =3D3D=3D3D Net::LDAP::LDAP_SUCCESS=
=3D91=3D
).<div class=3D3D"im"><br>
<br>
<blockquote class=3D3D"gmail_quote" style=3D3D"margin:0 0 0 .8ex;border-left:=
1p=3D
x #ccc solid;padding-left:1ex">
Apparently, my guess was wrong. =3DA0In that case, you probably hit<br>
ITS#6097 &lt;<a href=3D3D"http://www.openldap.org/its?findid=3D3D6097" target=
=3D
=3D3D"_blank">http://www.openldap.org/its?findid=3D3D6097</a>&gt;.<br>
</blockquote>
<br></div>
*hmmm* Good idea, thanks.<br>
But after reading ITS description I don=3D92t think it=3D92s =3DA0what troubl=
es m=3D
e.<br>
We don=3D92t actually neither have =3D84multi master mode=3D93, but =3D84mirr=
or mod=3D
e=3D93 and writes are done only on exactly one server, so there should not be=
=3D
 a problem with second server producing a concurrent write/modify.<br>
I=3D92d expect the delete to be correctly propagated, but I can=3D92t check i=
t =3D
is is, simply because I have to little knowledge to read debug log correctl=3D
y.</blockquote></div><div><br></div>Follow up:<div><br></div><div>I modifie=3D
d my test Perl script to do a &#39;ldapSearch&#39; after deleting and it re=3D
turns zero as number of found entries.</div>
<div>Sadly I have no idea, how to emulate &#39;-MM&#39; when using &#39;Net=3D
::LDAP&#39; and it&#39;s search function, so I can&#39;t check for &#39;glu=3D
e&#39; entries this way.</div><div>-- <br>Regards,
<div>Peter</div></div>

--001636988beae98b80047830ba81--



--===============7621560756465997858==--