directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harris, Christopher P" <chris_har...@baxter.com>
Subject RE: Proper use of LdapConnectionPool
Date Tue, 03 Feb 2015 23:26:03 GMT
Emmanuel/Stefan,

Yes.  I'm currently exploring this route.  It seems like the easier approach.

The only issue that I'm encountering now is that the AD admins have set a cap on the number
of returned entries to 20,000.

Our AD tree is primarily organized into global regions.  So, I can set each region as a search
base, construct a search filter that utilizes many criteria, and execute a search per region.
 Some regions will have to be broken into sub-regions, because some regions, such as North
America and Europe contain over 20,000 entries so far...

Still, I may need to employ multi-threading for each AD search against a region to speed things
along.  This entry compilation process will need to be quick, so I may get to employ some
of your suggestions, Stefan.

 - Chris


-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com] 
Sent: Tuesday, February 03, 2015 5:09 PM
To: api@directory.apache.org
Subject: Re: Proper use of LdapConnectionPool

Le 03/02/15 22:48, Stefan Seelmann a écrit :
> On 02/03/2015 10:19 PM, Emmanuel Lécharny wrote:
>> Le 03/02/15 22:07, Stefan Seelmann a écrit :
>>> I forgot to mention the performance aspect.
>>>
>>> If you traverse all persons from the CEO down you need as many LDAP 
>>> search operations as you have persons in the directory, each require 
>>> a full network roundtrip, which takes time.
>> What's the point of doing that when a ONE_LEVEL search done one level 
>> below would provide all the entries with one single Search ?
> If I understand Chris correctly the directory hierarchy and the 
> logical organisational hierarchy are different. For example:
>
> dn: cn=ceo,ou=c,ou=b,ou=a
> directreports: cn=jane,ou=x,ou=w,ou=a
> directreports: cn=john,ou=z,ou=y,ou=a
>
> If that is the case the "directreports" are not LDAP child entries, 
> but just pointer to somewhere in the directory tree. Similar to nested 
> group membership.

I see.

In this case, I would use a SubTree, and ditch entries that don't match the selection criteria.
I think that it would be faster than creating new connections on the flight, despite the outrageaous
number of entries transmoited. To be tested...


The information transmitted is intended only for the person(s) or entity to which it is addressed
and may contain confidential and/or legally privileged material. Delivery of this message
to any person other than the intended recipient(s) is not intended in any way to waive privilege
or confidentiality. Any review, retransmission, dissemination or other use of, or taking of
any action in reliance upon, this information by entities other than the intended recipient
is prohibited. If you receive this in error, please contact the sender and delete the material
from any computer.

For Translation:

http://www.baxter.com/email_disclaimer
Mime
View raw message