[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Problem chasing multiple referrals (ITS#799)

To: openldap-its@OpenLDAP.org
Subject: Re: Problem chasing multiple referrals (ITS#799)
From: Kurt@OpenLDAP.org
Date: Wed, 4 Oct 2000 22:04:03 GMT
The uploaded file was empty.  Can you re-upload (under a new
name).

Kurt

At 09:25 PM 10/4/00 +0000, VTAG@novell.com wrote:
>This is a MIME message. If you are reading this text, you may want to 
>consider changing to a mail reader or gateway that understands how to 
>properly handle MIME multipart messages.
>
>--=_0058EF2A.365735EB
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: quoted-printable
>
>
>I have submitted a patch to
>
>ftp://ftp.openldap.org/incoming/aclark-001004.patch
>
>The problem is caused by a deficiency in result.c:wait4msg()
>
>The scenario goes like this:
>
>Application does search_s
>Search_s calls result( )
>   result calls wait4msg(msgid=3D-1)
>   wait4msg calls read1msg(msgid=3D-1)
>   read1msg gets searchref on msgid=3D2
>   read1msg chases referral which calls simple bind - msgid =3D 4
>       bind_s calls result( msgid =3D 4)
>       result calls wait4msg, msgid =3D 4
>       wait4msg calls read1msg msgid=3D4
>       read1msg gets a searchref on msgid =3D 2
>       read1msg chases referral which calls simple-bind - msgid =3D 6
>          bind_s calls result( msgid =3D 6)
>          result calls wait4msg, msgid =3D 6
>          wait4msg calls read1msg msgid=3D6
>          read1msg gets msg with msgid=3D4
>              not looking for msgid=3D4, queue msg
>          wait4msg calls read1msg msgid=3D6
>          read1msg get msg with msgid=3D6
>          read1msg returns msg to wait4msg msgid=3D6
>          wait4msg returns msg to result msgid=3D6
>          result returns status to bind request msgid=3D6
>     read1msg returns no data to wait4msg
>     wait4msg calls read1msg msgid =3D 4
>     read1msg returns no data to wait4msg
>     ....
>     wait4msg calls read1msg msgid =3D 4
>     read1msg returns no data to wait4msg
>
>Because neither wait4msg nor try_read1msg look in the queue to see
>if the request is satisfied, wait4msg waits forever and the bind request
>with msgid=3D4 never returns.
>
>Result does however check the queue, but in this case it is too early.
>
>The patch makes the code that checks the queue a function and puts
>a check into wait4msg before calling read1msg.
>
>
>------------------------
>Steve Sonntag
>Novell, Inc., the leading provider of Net services software
>
>
>
>>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM >>>
>Full_Name: Stig Venaas
>Version: 2.0.4
>OS: Linux
>URL:=20
>Submission from: (NULL) (158.38.60.92)
>
>
>If I do
>
>ldapsearch -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*"
>
>I get two referrals, when following those and turning on debugging
>
>ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig=
>*"
>
>ldapsearch will hang, ending with:
>
>** Outstanding Requests:
>* msgid 5,  origid 2, status Request Completed
>   outstanding referrals 0, parent count 1
>* msgid 2,  origid 2, status Request Completed
>   outstanding referrals 1, parent count 0
>** Response Queue:
>* msgid 2,  type 100
>   chained responses:
>  * msgid 2,  type 100
>  * msgid 2,  type 100
>  * msgid 2,  type 100
>  * msgid 2,  type 100
>  * msgid 2,  type 100
>* msgid 4,  type 97
>do_ldap_select
>
>It looks like it got all the data it should, it just hasn't realised it. =
>The
>LDAP servers are publicly available so you can hopefully reproduce this. I =
>can
>try to debug more myself but some pointers would be nice, the code isn't
>trivial.
>
>Stig
>
>--=_0058EF2A.365735EB
>Content-Type: text/html; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> 
>I have submitted a patch to
> 
><3d.htm>ftp://ftp.open= ldap.org/incoming/aclark-001004.patch
> 
>The problem is caused by a deficiency in result.c:wait4msg()
> 
>The scenario goes like this:
> 
>Application does search_s
>Search_s calls result( )
>   result calls wait4msg(msgid=3D-1)
>   wait4msg calls read1msg(msgid=3D-1)
>   read1msg gets searchref on msgid=3D2
>   read1msg chases referral which calls simple = bind -=20 msgid =3D 4
>       bind_s calls result( msgid =3D = 4)
>       result calls wait4msg, msgid =3D = 4
>       wait4msg calls read1msg=20 msgid=3D4
>       read1msg gets a searchref on = msgid =3D=20 2
>       read1msg chases=20 referral which calls simple-bind - msgid =3D 6
>          bind_s calls = result(=20 msgid =3D 6)
>          result calls = wait4msg,=20 msgid =3D 6
>          wait4msg = calls=20 read1msg msgid=3D6
>          read1msg = gets=20 msg with msgid=3D4
>           &nbs=
>p;  not=20 looking for msgid=3D4, queue msg
>          wait4msg = calls=20 read1msg msgid=3D6
>          read1msg get = msg=20 with msgid=3D6
>          read1msg = returns msg=20 to wait4msg msgid=3D6
>          wait4msg = returns msg=20 to result msgid=3D6
>          result = returns=20 status to bind request msgid=3D6
>     read1msg returns no data to wait4msg 
>     wait4msg calls read1msg msgid =3D 4
>     read1msg returns no data to wait4msg
>     ....
>     wait4msg calls read1msg msgid =3D 4
>     read1msg returns no data to=20 wait4msg
> 
>Because neither wait4msg nor try_read1msg look in the queue to = see
>if the request is satisfied, wait4msg waits forever and the bind=20 request
>with msgid=3D4 never returns.
> 
>Result does however check the queue, but in this case it is too=20 early.
> 
>The patch makes the code that checks the queue a function and = puts
>a check into wait4msg before calling read1msg.
> 
> 
>------------------------
>Steve Sonntag
>Novell, Inc., the = leading=20 provider of Net services software
> 
> 
>
>>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM=20 >>>
>Full_Name: Stig Venaas
>Version: 2.0.4
>OS: Linux
>UR= L:=20 
>Submission from: (NULL) (158.38.60.92)
>
>
>If I do
>
>ldapse= arch=20 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*"
>
>I get two = referrals,=20 when following those and turning on debugging
>
>ldapsearch -C -d65535 = -h=20 sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*"
>
>ldapsearch = will hang,=20 ending with:
>
>** Outstanding Requests:
>* msgid 5,  origid = 2,=20 status Request Completed
>   outstanding referrals 0, parent = count=20 1
>* msgid 2,  origid 2, status Request Completed
>  =20= outstanding referrals 1, parent count 0
>** Response Queue:
>* = msgid=20 2,  type 100
>   chained responses:
>  * msgid = 2, =20 type 100
>  * msgid 2,  type 100
>  * msgid 2,  = type=20 100
>  * msgid 2,  type 100
>  * msgid 2,  type = 100
>*=20 msgid 4,  type 97
>do_ldap_select
>
>It looks like it got all = the=20 data it should, it just hasn't realised it. The
>LDAP servers are = publicly=20 available so you can hopefully reproduce this. I can
>try to debug more = myself=20 but some pointers would be nice, the code=20 isn't
>trivial.
>
>Stig
>
>--=_0058EF2A.365735EB--
Prev by Date: back-sql View instead of real table (ITS#805)
Next by Date: Re: Problem chasing multiple referrals (ITS#799)
Index(es):
- Chronological
- Thread