[Date Prev][Date Next] [Chronological] [Thread] [Top]
Re: Fw: OpenLDAP Search bug?

To: openldap-software@OpenLDAP.org
Subject: Re: Fw: OpenLDAP Search bug?
From: Banzaitron <banzaitron@adelphia.net>
Date: Tue, 10 Sep 2002 16:36:46 -0600
O one other thing I noticed.

As the LDAP is searching through the invalid entries (ones that are not
within the search scope) in this search, I see the following line before
each one:

bdb_search: 1836 scope not okay

The number is, I presume, the ID of the entry.

Andy

----- Original Message -----
From: "Banzaitron" <banzaitron@adelphia.net>
To: "Howard Chu" <hyc@symas.com>; <openldap-software@OpenLDAP.org>
Sent: Tuesday, September 10, 2002 2:47 PM
Subject: Re: Fw: OpenLDAP Search bug?


> Per Howard's request, here is the search information that produced that
log:
>
> startDN: "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com"
> filter: "(objectClass=wcomservice)"
> scope: 1
>
> There are only 10 entries under this uid, but it is searching through the
> whole tree.
>
> Andy
>
> ----- Original Message -----
> From: "Howard Chu" <hyc@symas.com>
> To: "Banzaitron" <banzaitron@adelphia.net>
> Sent: Tuesday, September 10, 2002 2:24 PM
> Subject: RE: Fw: OpenLDAP Search bug?
>
>
> > Please repost the search query and filter that produced this log.
> >
> >   -- Howard Chu
> >   Chief Architect, Symas Corp.       Director, Highland Sun
> >   http://www.symas.com               http://highlandsun.com/hyc
> >   Symas: Premier OpenSource Development and Support
> >
> > > -----Original Message-----
> > > From: owner-openldap-software@OpenLDAP.org
> > > [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Banzaitron
> > > Sent: Tuesday, September 10, 2002 12:35 PM
> > > To: Kurt D. Zeilenga
> > > Cc: openldap-software@OpenLDAP.org
> > > Subject: Re: Fw: OpenLDAP Search bug?
> > >
> > >
> > > OK, I redirected the output from my mystery search into a file (10
megs
> for
> > > one search!) and found the following interesting output at the
beginning
> of
> > > the search (where it is trying to determine the candidate set of
> > > entries for
> > > the search).  Note the "<= bdb_index_read: failed (-30990)" line:
> > >
> > > search_candidates:
> > > base="uid=5253257,ou=People,o=myorg,myorgroot=top,o=myorg.com"
> (0x00000698)
> > > scope=1
> > > => bdb_filter_candidates
> > >  AND
> > > => bdb_list_candidates 0xa0
> > > => bdb_filter_candidates
> > >  DN ONE
> > > => bdb_dn2idl(
> "uid=5253257,ou=people,o=myorg,myorgroot=top,o=myorg.com" )
> > > <= bdb_dn2idl: id=10 first=1689 last=1698
> > > <= bdb_filter_candidates: id=10 first=1689 last=1698
> > > => bdb_filter_candidates
> > >  OR
> > > => bdb_list_candidates 0xa1
> > > => bdb_filter_candidates
> > >  EQUALITY
> > > => bdb_equality_candidates
> > > => key_read
> > > <= bdb_index_read: failed (-30990)
> > > <= bdb_equality_candidates NULL
> > > <= bdb_equality_candidates id=0, first=0, last=0
> > > <= bdb_filter_candidates: id=0 first=0 last=0
> > > => bdb_filter_candidates
> > >  EQUALITY
> > > => bdb_equality_candidates
> > > => key_read
> > > <= bdb_index_read 15284 candidates
> > > <= bdb_equality_candidates id=15284, first=12, last=29997
> > > <= bdb_filter_candidates: id=15284 first=12 last=29997
> > > <= bdb_list_candidates: undefined rc=0
> > > <= bdb_filter_candidates: id=15284 first=12 last=29997
> > > <= bdb_list_candidates: undefined rc=0
> > > <= bdb_filter_candidates: id=15284 first=12 last=29997
> > > bdb_search_candidates: id=15284 first=12 last=29997
> > > ...
> > > <skipped 30000 entry searches>
> > >
> > > Apparently it is unable to read an index (what index I'm not
> > > sure?) and then
> > > decides that the entire tree is fair game for the search.  The
> > > following are
> > > my indices:
> > >
> > > index           ou,o            eq
> > > index           cn              pres,eq
> > > index           myorgfirstname,myorglastname,myorgvportalaccessinfo
> > > pres,eq,su
> > > b
> > > index           myorggroupname,myorgworkphonenumber      pres,eq,sub
> > > index           uid,myorgdn,myorgroot,myorgsn              pres,eq
> > > index           objectclass,myorgadmin,myorgan    pres,eq
> > > index           myorgsecondaryuid                pres,eq
> > >
> > > I'm using BDB 4.0.14, and the latest OpenLDAP build from engineering
> 2.1.X.
> > >
> > > Any clues where to go from here?  I have already rebuilt my indices
and
> > > deleted all data and reimported it, with no change in behavior.  I'm
> stuck
> > > with no clue how to proceed on this.
> > >
> > > Thanks,
> > > Andy
> > >
> > > ----- Original Message -----
> > > From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
> > > To: "Banzaitron" <banzaitron@adelphia.net>
> > > Cc: <openldap-software@OpenLDAP.org>
> > > Sent: Monday, September 09, 2002 4:26 PM
> > > Subject: Re: Fw: OpenLDAP Search bug?
> > >
> > >
> > > > At 02:35 PM 2002-09-09, Banzaitron wrote:
> > > > >I have set logging to show everything and the problem is that the
> > > candidate
> > > > >set as you call it is the ENTIRE TREE!!!  It is ignoring my start
DN
> and
> > > it
> > > > >is searching below AND above the DN I pass, regardless of the
search
> > > scope.
> > > >
> > > > In one of your previous post, you described one case where
> > > > you ONLY changed the filter from a (objectClass=*) to
> > > > (objectClass=myorgservice) caused the candidate to be
> > > > quite large (presumable all entries in the database).
> > > >
> > > > This is odd because, assuming everything else is equal
> > > > (including DN and scope), the latter search candidate
> > > > set should be subset of the former search candidate
> > > > set.
> > > >
> > > > Looking at the logs, one can determine which indexing
> > > > component(s) caused this oddity.
> > > >
> > > > You can do the same with DNs and scope subtree.  That is,
> > > > a search of a DN with scope subtree should have a
> > > > candidate set which is a subset of the search for its
> > > > parent with scope subtree.   If not, that would be odd.
> > > >
> > > > Looking at the logs, one can determine which indexing
> > > > component(s) caused this oddity.
> > > >
> > > > But a candidate set which happens to include an entry
> > > > which doesn't match all of the search criteria (including
> > > > DN, scope, filter, etc.) isn't odd.  It's called a
> > > > candidate set because it includes, in addition to
> > > > all entries which do match the criteria, some number
> > > > of entries that do not.  The number of these entries
> > > > depends on how effective the indexing system was on
> > > > reducing the candidate set from all entries to the
> > > > subset of entries matching all of the search criteria.
> > > >
> > > > Kurt
> > > >
> > >
> > >
> > >
> >
>
Prev by Date: Re: Fw: OpenLDAP Search bug?
Next by Date: Re: Replicate only a part of the tree
Index(es):
- Chronological
- Thread