ldap-sdk-discuss — Discussions related to the LDAP SDK for Java

Re: [ldap-sdk-discuss] LDAP SDK Java question

[Neil A. W. <nei...@un...>]

On 09/20/2016 08:45 AM, Kasim Doctor wrote:
> Hi Neil,
> 
> Thanks for your quick reply.
> 
> 
> 
> *I know that with the UnboundID Directory Server, we do guarantee that
> superior entries will be returned before any of their subordinates, with
> only a couple of exceptions (for example, searches including the
> server-side sort or persistent search request control)*
> Can you please point me to a spec/Javadoc for the above statement ?
> 
> Thanks,
> Kasim

There certainly isn't anything in the LDAP SDK javadoc that would make
that statement.  I'm not sure if that statement appears in the UnboundID
Directory Server documentation, but that isn't currently publicly available.

Nevertheless, I am the lead developer for the UnboundID Directory
Server, and I can assure you that we do guarantee that the UnboundID
Directory Server will return superior entries before subordinates unless
the search request includes something special that would alter the order
in which those entries are returned.




> 
> On Mon, Sep 19, 2016 at 4:46 PM, Neil A. Wilson <nei...@un...>
> wrote:
> 
>> On 09/19/2016 12:21 PM, Kasim Doctor wrote:
>>> Hi there,
>>>
>>> I am playing around with the LDAP Java SDK API to get a list of OUs from
>> a
>>> source directory.
>>>
>>> I searched everywhere but can't seem to find the answer to the following
>>> question:
>>>
>>> When I get the list of OUs, what guarantee is there that the parent OUs
>> are
>>> returned before the child OUs are returned ?
>>>
>>> Please let me know if there is a spec somewhere for this
>>>
>>> Thanks,
>>> Kasim
>>
>>
>> There is no specification that requires a superior entry to be returned
>> in search results before its subordinates.  In fact, RFC 4511 section
>> 4.5.2 states "The SearchResultEntry and SearchResultReference messages
>> may come in any order.", so it would be legal for subordinate entries to
>> be returned before their superiors.
>>
>> However, I expect that most LDAP servers do try to return superior
>> entries before subordinates.  I know that with the UnboundID Directory
>> Server, we do guarantee that superior entries will be returned before
>> any of their subordinates, with only a couple of exceptions (for
>> example, searches including the server-side sort or persistent search
>> request control). I can't speak definitively for other directory
>> servers, but I expect that most servers do try to maintain this ordering
>> under normal circumstances.
>>
>> If you're really paranoid about this, and if you expect that your search
>> won't return a large number of entries, you can have the LDAP SDK sort
>> the results for you, and you can specify that the sorting should order
>> each entry first based on its position in the hierarchy and then based
>> on its content.  See the EntrySorter
>> (https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?
>> com/unboundid/ldap/sdk/EntrySorter.html)
>> class for more information.  However, client-side sorting can only be
>> done if you can hold all of the entries in memory, so you shouldn't do
>> this if you think there might be a large number of matching entries.
>>
>>
>> Neil
>>
>>
>>
> 

[ldap-sdk-discuss] Support for SASL GSS-SPNEGO mechanism

[Sergey K. <skl...@op...>]

Hello,

Does UnboundID LDAP SDK have any plans to implement SASL GSS-SPNEGO bind class?

What is the best way to implement SASL GSS-SPNEGO mechanism now?
Using GenericSASLBindRequest, I can do successful GSS-SPNEGO bind.
However connection, used in bind request, doesn't use GSS API wrapper. Connection still sends clear search requests.

Thanks in advance,
Sergey

[ldap-sdk-discuss] Can not search with GenericSASLBindRequest

[Sergey K. <skl...@op...>]

Hello,
I do bind to AD with GenericSASLBindRequest, using Kerberos token.

byte[] kerberosToken = getKerberosToken(user, password);
ASN1OctetString credentials = new ASN1OctetString(kerberosToken);

GenericSASLBindRequest genericSASLBindRequest = new GenericSASLBindRequest(null, "GSS-SPNEGO", credentials, null);
bindResult = ldapConnection.bind(genericSASLBindRequest);

Bind succeeds!!!
However, when I try to do search on the same connection, search still goes without any Kerberos and obviously AD doesn't respond.
What should I do to force connection to use Kerberos on search requests?

Thanks in advance,
Sergey

Re: [ldap-sdk-discuss] LDAP SDK Java question

[Kasim D. <kas...@gm...>]

Hi Neil,

Thanks for your quick reply.



*I know that with the UnboundID Directory Server, we do guarantee that
superior entries will be returned before any of their subordinates, with
only a couple of exceptions (for example, searches including the
server-side sort or persistent search request control)*
Can you please point me to a spec/Javadoc for the above statement ?

Thanks,
Kasim

On Mon, Sep 19, 2016 at 4:46 PM, Neil A. Wilson <nei...@un...>
wrote:

> On 09/19/2016 12:21 PM, Kasim Doctor wrote:
> > Hi there,
> >
> > I am playing around with the LDAP Java SDK API to get a list of OUs from
> a
> > source directory.
> >
> > I searched everywhere but can't seem to find the answer to the following
> > question:
> >
> > When I get the list of OUs, what guarantee is there that the parent OUs
> are
> > returned before the child OUs are returned ?
> >
> > Please let me know if there is a spec somewhere for this
> >
> > Thanks,
> > Kasim
>
>
> There is no specification that requires a superior entry to be returned
> in search results before its subordinates.  In fact, RFC 4511 section
> 4.5.2 states "The SearchResultEntry and SearchResultReference messages
> may come in any order.", so it would be legal for subordinate entries to
> be returned before their superiors.
>
> However, I expect that most LDAP servers do try to return superior
> entries before subordinates.  I know that with the UnboundID Directory
> Server, we do guarantee that superior entries will be returned before
> any of their subordinates, with only a couple of exceptions (for
> example, searches including the server-side sort or persistent search
> request control). I can't speak definitively for other directory
> servers, but I expect that most servers do try to maintain this ordering
> under normal circumstances.
>
> If you're really paranoid about this, and if you expect that your search
> won't return a large number of entries, you can have the LDAP SDK sort
> the results for you, and you can specify that the sorting should order
> each entry first based on its position in the hierarchy and then based
> on its content.  See the EntrySorter
> (https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?
> com/unboundid/ldap/sdk/EntrySorter.html)
> class for more information.  However, client-side sorting can only be
> done if you can hold all of the entries in memory, so you shouldn't do
> this if you think there might be a large number of matching entries.
>
>
> Neil
>
>
>

Re: [ldap-sdk-discuss] LDAP SDK Java question

[Neil A. W. <nei...@un...>]

On 09/19/2016 12:21 PM, Kasim Doctor wrote:
> Hi there,
> 
> I am playing around with the LDAP Java SDK API to get a list of OUs from a
> source directory.
> 
> I searched everywhere but can't seem to find the answer to the following
> question:
> 
> When I get the list of OUs, what guarantee is there that the parent OUs are
> returned before the child OUs are returned ?
> 
> Please let me know if there is a spec somewhere for this
> 
> Thanks,
> Kasim


There is no specification that requires a superior entry to be returned
in search results before its subordinates.  In fact, RFC 4511 section
4.5.2 states "The SearchResultEntry and SearchResultReference messages
may come in any order.", so it would be legal for subordinate entries to
be returned before their superiors.

However, I expect that most LDAP servers do try to return superior
entries before subordinates.  I know that with the UnboundID Directory
Server, we do guarantee that superior entries will be returned before
any of their subordinates, with only a couple of exceptions (for
example, searches including the server-side sort or persistent search
request control). I can't speak definitively for other directory
servers, but I expect that most servers do try to maintain this ordering
under normal circumstances.

If you're really paranoid about this, and if you expect that your search
won't return a large number of entries, you can have the LDAP SDK sort
the results for you, and you can specify that the sorting should order
each entry first based on its position in the hierarchy and then based
on its content.  See the EntrySorter
(https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/EntrySorter.html)
class for more information.  However, client-side sorting can only be
done if you can hold all of the entries in memory, so you shouldn't do
this if you think there might be a large number of matching entries.


Neil

[ldap-sdk-discuss] LDAP SDK Java question

[Kasim D. <kas...@gm...>]

Hi there,

I am playing around with the LDAP Java SDK API to get a list of OUs from a
source directory.

I searched everywhere but can't seem to find the answer to the following
question:

When I get the list of OUs, what guarantee is there that the parent OUs are
returned before the child OUs are returned ?

Please let me know if there is a spec somewhere for this

Thanks,
Kasim

Re: [ldap-sdk-discuss] fetching operational attributes of an objectClass

[Neil A. W. <nei...@un...>]

On 09/13/2016 04:32 PM, Priya Parul wrote:
> Hi,
> 
> We use UnboundId java sdk to talk to various ldap servers. I'm using the methods ObjectClassDefinition::getRequiredAttributes() and getOperationalAttributes(), to get the attributes of an objectClass. But these methods don't return the operational attributes of the objectClass. Could someone point me to how to get the operational attributes in the java sdk? I would really appreciate some pointers.
> 
> Thanks,
> 
> Priya.

Operational attributes are generally not included in object classes
because they don't need to be.  In general, unless the server does
something to prevent it, any operational attribute may appear in any
entry regardless of that entry's object classes.

Note, however, that some operational attribute definitions may include
the NO-USER-MODIFICATION constraint, in which case clients won't be
permitted to alter their values.  Further, the server may impose access
control constraints or other types of limits to control which users may
interact with operational attributes.


Neil

[ldap-sdk-discuss] fetching operational attributes of an objectClass

[Priya P. <pri...@ok...>]

Hi,

We use UnboundId java sdk to talk to various ldap servers. I'm using the methods ObjectClassDefinition::getRequiredAttributes() and getOperationalAttributes(), to get the attributes of an objectClass. But these methods don't return the operational attributes of the objectClass. Could someone point me to how to get the operational attributes in the java sdk? I would really appreciate some pointers.

Thanks,

Priya.

Re: [ldap-sdk-discuss] LDAPConnection pool and paged search

[Sergey K. <skl...@op...>]

Thank you, Neil
I'll try and let you know.
Sergey

-----Original Message-----
From: Neil A. Wilson [mailto:nei...@un...] 
Sent: Monday, August 08, 2016 4:59 PM
To: LDAP SDK Discussions <lda...@li...>
Subject: Re: [ldap-sdk-discuss] LDAPConnection pool and paged search

The LDAP SDK will definitely let you reuse a simple paged results cookie across multiple connections, but whether or not the server will support it is another matter, and that's dependent on the server's simple paged results control implementation.  It will work in the UnboundID Directory Server, but given that you are occasionally running into an error when trying it against Active Directory (at least, I assume from the error message that you're using Active Directory) that it may not be supported in that server.

If you're going to use a simple paged results control against a server that you don't know supports using a cookie across multiple connections, then it would be safest to check out a connection from the pool, use that connection to retrieve all pages of results, and then release that connection back to the pool.


Neil Wilson



On 08/08/2016 03:09 PM, Sergey Klyushin wrote:
> Hello,
> Can I use LDAPConnectionPool for paged search (or other search requests that uses cookie returned from the LDAP server)?
> It works for me most of the time, but once in a while I get error
> 
> LDAPSearchException(resultCode=12 (unavailable critical extension), numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: DSID-0C090797, comment: Error processing control, data 0, v23f0 ')
>                 at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)
>                 at 
> com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectio
> nPool.java:2020)
> 
> I believe it happens, because new connection is used with cookie returned from previous call. I can see that new port is used in search request.
> 
> My code is something like this:
> 
> private LDAPConnection createNewLDAPConnection(String host, int port, boolean useSSL) throws LDAPException {
>     LDAPConnectionOptions ldapConnectionOptions = new 
> LDAPConnectionOptions();
> 
>     ldapConnectionOptions.setAutoReconnect(true);
>     ldapConnectionOptions.setUseKeepAlive(true);
>     ldapConnectionOptions.setUseTCPNoDelay(true);
>     ldapConnectionOptions.setUseSynchronousMode(true);
>     ldapConnectionOptions.setFollowReferrals(false);
>     ldapConnectionOptions.setResponseTimeoutMillis(0);
> 
> 
>     SocketFactory sf = null;
>     LDAPConnection ldapConnection = new LDAPConnection(sf, ldapConnectionOptions, host, port);
>     if (!StringsUtils.isBlank(m_bindUser) && !StringsUtils.isBlank(m_bindPassword)) {
>         ldapConnection.bind(m_bindUser, m_bindPassword);
>     }
>     return ldapConnection;
> }
> 
> 
> LDAPConnection ldapConnection = 
> createNewLDAPConnection(m_prevConnectedUrl);
> 
> m_connectionPool = new LDAPConnectionPool(ldapConnection, 3);
> 
> 
> 
> ......
> 
> 
> 
> // do search. Called while getting back results with PagedControl
> 
> 
> 
> protected SearchResult doSearch(String parentPrefix, SearchRequest 
> searchRequest, Control[] controls) {
> 
> 
> 
> .....
> 
> if (controls != null) {
>     searchRequest.setControls(controls);  // Paged control with cookie 
> from previous response }
> 
> 
> 
> searchResult = m_connectionPool.search(searchRequest);
> 
> 
> 
> }
> 
> 
> 
> 
> 
> I can see that most of the time
> 
> searchResult = m_connectionPool.search(searchRequest);
> 
> succeeds, but at some moment fails with
> 
> 
> 
> LDAPSearchException(resultCode=12 (unavailable critical extension), 
> numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: 
> DSID-0C090797, comment: Error processing control, data 0, v23f0 ')
> 
>          at 
> com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)
> 
>          at 
> com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectio
> nPool.java:2020)
> 
> 
> 
> Looks like it fails, because call comes from different port (another 
> connection)
> 
> Am I right?
> 
> What would you suggest?
> 
> Should I use for paged searches (and other searches that use cookies) 
> dedicated connection? Something like
> 
> LDAPConnection connection = m_connectionPool.getConnection();
> 
> 
> 
> While (have results) {
> 
>          connection.search(); // with updated cookie in paged search 
> contro
> 
> }
> 
> 
> 
> Should I release connection?
> 
> 
> 
> 
> 
> Thanks in advance,
> 
> Sergey
> 
> 
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------
> -------- What NetFlow Analyzer can do for you? Monitors network 
> bandwidth and traffic patterns at an interface-level. Reveals which 
> users, apps, and protocols are consuming the most bandwidth. Provides 
> multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make 
> informed decisions using capacity planning reports. 
> http://sdm.link/zohodev2dev
> 
> 
> 
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> 

Re: [ldap-sdk-discuss] LDAPConnection pool and paged search

[Neil A. W. <nei...@un...>]

The LDAP SDK will definitely let you reuse a simple paged results cookie
across multiple connections, but whether or not the server will support
it is another matter, and that's dependent on the server's simple paged
results control implementation.  It will work in the UnboundID Directory
Server, but given that you are occasionally running into an error when
trying it against Active Directory (at least, I assume from the error
message that you're using Active Directory) that it may not be supported
in that server.

If you're going to use a simple paged results control against a server
that you don't know supports using a cookie across multiple connections,
then it would be safest to check out a connection from the pool, use
that connection to retrieve all pages of results, and then release that
connection back to the pool.


Neil Wilson



On 08/08/2016 03:09 PM, Sergey Klyushin wrote:
> Hello,
> Can I use LDAPConnectionPool for paged search (or other search requests that uses cookie returned from the LDAP server)?
> It works for me most of the time, but once in a while I get error
> 
> LDAPSearchException(resultCode=12 (unavailable critical extension), numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: DSID-0C090797, comment: Error processing control, data 0, v23f0 ')
>                 at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)
>                 at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020)
> 
> I believe it happens, because new connection is used with cookie returned from previous call. I can see that new port is used in search request.
> 
> My code is something like this:
> 
> private LDAPConnection createNewLDAPConnection(String host, int port, boolean useSSL) throws LDAPException {
>     LDAPConnectionOptions ldapConnectionOptions = new LDAPConnectionOptions();
> 
>     ldapConnectionOptions.setAutoReconnect(true);
>     ldapConnectionOptions.setUseKeepAlive(true);
>     ldapConnectionOptions.setUseTCPNoDelay(true);
>     ldapConnectionOptions.setUseSynchronousMode(true);
>     ldapConnectionOptions.setFollowReferrals(false);
>     ldapConnectionOptions.setResponseTimeoutMillis(0);
> 
> 
>     SocketFactory sf = null;
>     LDAPConnection ldapConnection = new LDAPConnection(sf, ldapConnectionOptions, host, port);
>     if (!StringsUtils.isBlank(m_bindUser) && !StringsUtils.isBlank(m_bindPassword)) {
>         ldapConnection.bind(m_bindUser, m_bindPassword);
>     }
>     return ldapConnection;
> }
> 
> 
> LDAPConnection ldapConnection = createNewLDAPConnection(m_prevConnectedUrl);
> 
> m_connectionPool = new LDAPConnectionPool(ldapConnection, 3);
> 
> 
> 
> ......
> 
> 
> 
> // do search. Called while getting back results with PagedControl
> 
> 
> 
> protected SearchResult doSearch(String parentPrefix, SearchRequest searchRequest, Control[] controls) {
> 
> 
> 
> .....
> 
> if (controls != null) {
>     searchRequest.setControls(controls);  // Paged control with cookie from previous response
> }
> 
> 
> 
> searchResult = m_connectionPool.search(searchRequest);
> 
> 
> 
> }
> 
> 
> 
> 
> 
> I can see that most of the time
> 
> searchResult = m_connectionPool.search(searchRequest);
> 
> succeeds, but at some moment fails with
> 
> 
> 
> LDAPSearchException(resultCode=12 (unavailable critical extension), numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: DSID-0C090797, comment: Error processing control, data 0, v23f0 ')
> 
>          at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)
> 
>          at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020)
> 
> 
> 
> Looks like it fails, because call comes from different port (another connection)
> 
> Am I right?
> 
> What would you suggest?
> 
> Should I use for paged searches (and other searches that use cookies) dedicated connection? Something like
> 
> LDAPConnection connection = m_connectionPool.getConnection();
> 
> 
> 
> While (have results) {
> 
>          connection.search(); // with updated cookie in paged search contro
> 
> }
> 
> 
> 
> Should I release connection?
> 
> 
> 
> 
> 
> Thanks in advance,
> 
> Sergey
> 
> 
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are 
> consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
> J-Flow, sFlow and other flows. Make informed decisions using capacity 
> planning reports. http://sdm.link/zohodev2dev
> 
> 
> 
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
> 

[ldap-sdk-discuss] LDAPConnection pool and paged search

[Sergey K. <skl...@op...>]

Hello,
Can I use LDAPConnectionPool for paged search (or other search requests that uses cookie returned from the LDAP server)?
It works for me most of the time, but once in a while I get error

LDAPSearchException(resultCode=12 (unavailable critical extension), numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: DSID-0C090797, comment: Error processing control, data 0, v23f0 ')
                at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)
                at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020)

I believe it happens, because new connection is used with cookie returned from previous call. I can see that new port is used in search request.

My code is something like this:

private LDAPConnection createNewLDAPConnection(String host, int port, boolean useSSL) throws LDAPException {
    LDAPConnectionOptions ldapConnectionOptions = new LDAPConnectionOptions();

    ldapConnectionOptions.setAutoReconnect(true);
    ldapConnectionOptions.setUseKeepAlive(true);
    ldapConnectionOptions.setUseTCPNoDelay(true);
    ldapConnectionOptions.setUseSynchronousMode(true);
    ldapConnectionOptions.setFollowReferrals(false);
    ldapConnectionOptions.setResponseTimeoutMillis(0);


    SocketFactory sf = null;
    LDAPConnection ldapConnection = new LDAPConnection(sf, ldapConnectionOptions, host, port);
    if (!StringsUtils.isBlank(m_bindUser) && !StringsUtils.isBlank(m_bindPassword)) {
        ldapConnection.bind(m_bindUser, m_bindPassword);
    }
    return ldapConnection;
}


LDAPConnection ldapConnection = createNewLDAPConnection(m_prevConnectedUrl);

m_connectionPool = new LDAPConnectionPool(ldapConnection, 3);



......



// do search. Called while getting back results with PagedControl



protected SearchResult doSearch(String parentPrefix, SearchRequest searchRequest, Control[] controls) {



.....

if (controls != null) {
    searchRequest.setControls(controls);  // Paged control with cookie from previous response
}



searchResult = m_connectionPool.search(searchRequest);



}





I can see that most of the time

searchResult = m_connectionPool.search(searchRequest);

succeeds, but at some moment fails with



LDAPSearchException(resultCode=12 (unavailable critical extension), numEntries=0, numReferences=0, errorMessage='00000057: LdapErr: DSID-0C090797, comment: Error processing control, data 0, v23f0 ')

         at com.unboundid.ldap.sdk.LDAPConnection.search(LDAPConnection.java:3658)

         at com.unboundid.ldap.sdk.AbstractConnectionPool.search(AbstractConnectionPool.java:2020)



Looks like it fails, because call comes from different port (another connection)

Am I right?

What would you suggest?

Should I use for paged searches (and other searches that use cookies) dedicated connection? Something like

LDAPConnection connection = m_connectionPool.getConnection();



While (have results) {

         connection.search(); // with updated cookie in paged search contro

}



Should I release connection?





Thanks in advance,

Sergey

Re: [ldap-sdk-discuss] LDAP connection pool behaviour

[Vladimir D. <vla...@co...>]

Hi Neil,

It turned out that the LDAP server was getting bogged down, which then
caused a pile up of requests and connections waiting to be served.
Monitoring pool and server seems crucial here.

The connection pool stats bug was reported by us, thanks for fixing it.
There's no apparent change of behaviour between 3.1.1 and 3.1.0 as seen
from our side.

Thank

Vladimir

On 12/05/16 11:20, Vladimir Dzhuvinov wrote:
> Thanks Neil for your comprehensive response. You need to digest it
> first, and then we'll get back to you.
>
> Vladimir
>
> On 12/05/16 09:05, Neil A. Wilson wrote:
>> Sorry for the late response. My comments are inline below.
>>
>> Neil
>>
>>
>> On 05/11/2016 05:40 AM, Vladimir Dzhuvinov wrote:
>>> Hi,
>>>
>>> I would like to report on some recently observed behaviour of the LDAP
>>> connection pool in v3.3.1.
>> Does it seem that the 3.3.1 version is behaving differently than the
>> previous version that you were using, or is it possible that this
>> behavior also exists in older versions?
>>
>> The only change to the connection pool implementation between the 3.3.0
>> and 3.3.1 releases is a very minor update to fix a bug that prevented
>> connection pool statistics from recording a failed attempt to establish
>> a new connection in certain circumstances, and I can't see how that
>> change would lead to any case in which the number of connections in the
>> pool grows.
>>
>> There were a couple of changes between the 3.0.0 and 3.1.0 releases, but
>> I've reviewed those changes and none of them seem to have the potential
>> to cause a regression like what you're reporting.
>>
>>
>>
>>> The setup looks like this:
>>>
>>> 8 LDAP clients, each on the node of a clustered web app.
>>>
>>> Each LDAP client is configured with an LDAP connection pool:
>>>
>>> * Initial number of connections: 0
>>> * Max number of connections: 1024
>>> * Max connection wait time: 500ms
>>> * Max connection age: 0
>>>
>>>
>>> LDAP requests are run against the pool, i.e. connections are not checked
>>> out, then returned.
>>>
>>>
>>> With this setup and the typical app load the number of available
>>> connections settles to ~200. On several occasions however, when a new
>>> LDAP client / app node is started, the pool is slow to create new
>>> connections, settling to about 5 to 10, and leading to a degraded app
>>> performance. To address this, the setting for the initial number of
>>> connections was raised to 50. With this setup however, the pooled
>>> connections immediately jumped to the max limit (~1000).
>> It doesn't make sense that merely changing the initial number of
>> connections would cause the total number of connections to increase.
>> Once the initial connections have been established, the pool should only
>> create new connections if one is needed when all of the existing
>> connections are already in use.
>>
>> At least in theory, the only way that you should end up with 1000
>> connections established as part of the pool is to have a situation in
>> which you have 1000 threads in your application all trying to process
>> LDAP operations at the same time. Do you think that it's reasonable that
>> your application might be processing 1000 LDAP requests simultaneously?
>>
>> Note that the number of connections in the pool won't go down on its
>> own. You either need to call discardConnection or shrinkPool to have the
>> pool get rid of connections. In all other circumstances, if a connection
>> needs to be closed then the pool will try to replace it with a
>> newly-established connection. So if you have 1000 connections, then that
>> doesn't mean that all 1000 of them are busy right now, but it should
>> indicate that 1000 simultaneous connections were needed at some point in
>> the life of the pool.
>>
>> Have you looked at the connection pool statistics to see if its numbers
>> match what you're seeing?  If a pool has 1000 connections, then
>> getNumSuccessfulConnectionAttempts should return a value that is 1000
>> more than the sum of the values returned by the
>> getNumConnectionsClosedDefunct, getNumConnectionsClosedExpired, and
>> getNumConnectionsClosedUnneeded methods.
>>
>>
>>
>>> My question: is there any recipe or configuration strategy to ensure the
>>> pooled connection count is a good match for the LDAP request
>>> requirements of the client?
>> Unless your client is doing some very weird things, you shouldn't need
>> more than one connection per application thread.  And the only scenarios
>> I can think of that might be able to allocate more than one connection
>> per thread would require you to check out and release connections
>> yourself, but it sounds like you're not doing that.
>>
>>
>>
>>> We also ran a few simple tests that showed different connection build up
>>> with checked out LDAP connections, vs running requests against the pool.
>>> What is the preferred way to run LDAP requests for stable performance
>>> and optimal utilisation of the pooled connections?
>> I'm not sure why you would see any difference in the accumulation of
>> connections when you let the pool check out and release connections in
>> the course of processing an operation and when you check out and release
>> the connections for yourself.  Letting the pool do it for you enables
>> the potential for using additional functionality that you can't get when
>> checking out and restoring the connections for yourself (for example,
>> automatically retrying a failed operation on a newly-established
>> connection), and also simplifies your application code, so I would
>> recommend going with that approach.  But ultimately, if you have the
>> pool check out and release connections for you, then it should be using
>> exactly the same methods to check out and release connections that you
>> would use if you were doing it yourself.
>>
>> Do you have any kind of reproducible test case that you could provide to
>> demonstrate the problem?  If not, would you be able to provide the code
>> that you're using to create and manage the connection pool (in
>> particular, the constructor you're using, along with any calls to setter
>> methods for customizing the pool behavior, like enabling retry, setting
>> a maximum connection age, configuring a health check, etc.)?  Feel free
>> to obscure or hide any sensitive information, since it's more about
>> understanding what calls you're making than exactly what arguments are
>> provided.
>>
>>
>>
>>> Any suggestions or insights will be appreciated.
>>>
>>> Thanks,
>>>
>>>
>>> Vladimir
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Mobile security can be enabling, not merely restricting. Employees who
>> bring their own devices (BYOD) to work are irked by the imposition of MDM
>> restrictions. Mobile Device Manager Plus allows you to control only the
>> apps on BYO-devices by containerizing them, leaving personal data untouched!
>> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>>
>>
>> _______________________________________________
>> ldap-sdk-discuss mailing list
>> lda...@li...
>> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>
>
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss

-- 
Vladimir Dzhuvinov :: vla...@co...

Re: [ldap-sdk-discuss] LDAP connection pool behaviour

[Vladimir D. <vla...@co...>]

Thanks Neil for your comprehensive response. You need to digest it
first, and then we'll get back to you.

Vladimir

On 12/05/16 09:05, Neil A. Wilson wrote:
> Sorry for the late response. My comments are inline below.
>
> Neil
>
>
> On 05/11/2016 05:40 AM, Vladimir Dzhuvinov wrote:
>> Hi,
>>
>> I would like to report on some recently observed behaviour of the LDAP
>> connection pool in v3.3.1.
> Does it seem that the 3.3.1 version is behaving differently than the
> previous version that you were using, or is it possible that this
> behavior also exists in older versions?
>
> The only change to the connection pool implementation between the 3.3.0
> and 3.3.1 releases is a very minor update to fix a bug that prevented
> connection pool statistics from recording a failed attempt to establish
> a new connection in certain circumstances, and I can't see how that
> change would lead to any case in which the number of connections in the
> pool grows.
>
> There were a couple of changes between the 3.0.0 and 3.1.0 releases, but
> I've reviewed those changes and none of them seem to have the potential
> to cause a regression like what you're reporting.
>
>
>
>> The setup looks like this:
>>
>> 8 LDAP clients, each on the node of a clustered web app.
>>
>> Each LDAP client is configured with an LDAP connection pool:
>>
>> * Initial number of connections: 0
>> * Max number of connections: 1024
>> * Max connection wait time: 500ms
>> * Max connection age: 0
>>
>>
>> LDAP requests are run against the pool, i.e. connections are not checked
>> out, then returned.
>>
>>
>> With this setup and the typical app load the number of available
>> connections settles to ~200. On several occasions however, when a new
>> LDAP client / app node is started, the pool is slow to create new
>> connections, settling to about 5 to 10, and leading to a degraded app
>> performance. To address this, the setting for the initial number of
>> connections was raised to 50. With this setup however, the pooled
>> connections immediately jumped to the max limit (~1000).
> It doesn't make sense that merely changing the initial number of
> connections would cause the total number of connections to increase.
> Once the initial connections have been established, the pool should only
> create new connections if one is needed when all of the existing
> connections are already in use.
>
> At least in theory, the only way that you should end up with 1000
> connections established as part of the pool is to have a situation in
> which you have 1000 threads in your application all trying to process
> LDAP operations at the same time. Do you think that it's reasonable that
> your application might be processing 1000 LDAP requests simultaneously?
>
> Note that the number of connections in the pool won't go down on its
> own. You either need to call discardConnection or shrinkPool to have the
> pool get rid of connections. In all other circumstances, if a connection
> needs to be closed then the pool will try to replace it with a
> newly-established connection. So if you have 1000 connections, then that
> doesn't mean that all 1000 of them are busy right now, but it should
> indicate that 1000 simultaneous connections were needed at some point in
> the life of the pool.
>
> Have you looked at the connection pool statistics to see if its numbers
> match what you're seeing?  If a pool has 1000 connections, then
> getNumSuccessfulConnectionAttempts should return a value that is 1000
> more than the sum of the values returned by the
> getNumConnectionsClosedDefunct, getNumConnectionsClosedExpired, and
> getNumConnectionsClosedUnneeded methods.
>
>
>
>> My question: is there any recipe or configuration strategy to ensure the
>> pooled connection count is a good match for the LDAP request
>> requirements of the client?
> Unless your client is doing some very weird things, you shouldn't need
> more than one connection per application thread.  And the only scenarios
> I can think of that might be able to allocate more than one connection
> per thread would require you to check out and release connections
> yourself, but it sounds like you're not doing that.
>
>
>
>> We also ran a few simple tests that showed different connection build up
>> with checked out LDAP connections, vs running requests against the pool.
>> What is the preferred way to run LDAP requests for stable performance
>> and optimal utilisation of the pooled connections?
> I'm not sure why you would see any difference in the accumulation of
> connections when you let the pool check out and release connections in
> the course of processing an operation and when you check out and release
> the connections for yourself.  Letting the pool do it for you enables
> the potential for using additional functionality that you can't get when
> checking out and restoring the connections for yourself (for example,
> automatically retrying a failed operation on a newly-established
> connection), and also simplifies your application code, so I would
> recommend going with that approach.  But ultimately, if you have the
> pool check out and release connections for you, then it should be using
> exactly the same methods to check out and release connections that you
> would use if you were doing it yourself.
>
> Do you have any kind of reproducible test case that you could provide to
> demonstrate the problem?  If not, would you be able to provide the code
> that you're using to create and manage the connection pool (in
> particular, the constructor you're using, along with any calls to setter
> methods for customizing the pool behavior, like enabling retry, setting
> a maximum connection age, configuring a health check, etc.)?  Feel free
> to obscure or hide any sensitive information, since it's more about
> understanding what calls you're making than exactly what arguments are
> provided.
>
>
>
>>
>> Any suggestions or insights will be appreciated.
>>
>> Thanks,
>>
>>
>> Vladimir
>>
>
>
>
> ------------------------------------------------------------------------------
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
>
>
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss

-- 
Vladimir Dzhuvinov :: vla...@co...

Re: [ldap-sdk-discuss] LDAP connection pool behaviour

[Neil A. W. <nei...@un...>]

Sorry for the late response. My comments are inline below.

Neil


On 05/11/2016 05:40 AM, Vladimir Dzhuvinov wrote:
> Hi,
> 
> I would like to report on some recently observed behaviour of the LDAP
> connection pool in v3.3.1.

Does it seem that the 3.3.1 version is behaving differently than the
previous version that you were using, or is it possible that this
behavior also exists in older versions?

The only change to the connection pool implementation between the 3.3.0
and 3.3.1 releases is a very minor update to fix a bug that prevented
connection pool statistics from recording a failed attempt to establish
a new connection in certain circumstances, and I can't see how that
change would lead to any case in which the number of connections in the
pool grows.

There were a couple of changes between the 3.0.0 and 3.1.0 releases, but
I've reviewed those changes and none of them seem to have the potential
to cause a regression like what you're reporting.



> The setup looks like this:
> 
> 8 LDAP clients, each on the node of a clustered web app.
> 
> Each LDAP client is configured with an LDAP connection pool:
> 
> * Initial number of connections: 0
> * Max number of connections: 1024
> * Max connection wait time: 500ms
> * Max connection age: 0
> 
> 
> LDAP requests are run against the pool, i.e. connections are not checked
> out, then returned.
> 
> 
> With this setup and the typical app load the number of available
> connections settles to ~200. On several occasions however, when a new
> LDAP client / app node is started, the pool is slow to create new
> connections, settling to about 5 to 10, and leading to a degraded app
> performance. To address this, the setting for the initial number of
> connections was raised to 50. With this setup however, the pooled
> connections immediately jumped to the max limit (~1000).

It doesn't make sense that merely changing the initial number of
connections would cause the total number of connections to increase.
Once the initial connections have been established, the pool should only
create new connections if one is needed when all of the existing
connections are already in use.

At least in theory, the only way that you should end up with 1000
connections established as part of the pool is to have a situation in
which you have 1000 threads in your application all trying to process
LDAP operations at the same time. Do you think that it's reasonable that
your application might be processing 1000 LDAP requests simultaneously?

Note that the number of connections in the pool won't go down on its
own. You either need to call discardConnection or shrinkPool to have the
pool get rid of connections. In all other circumstances, if a connection
needs to be closed then the pool will try to replace it with a
newly-established connection. So if you have 1000 connections, then that
doesn't mean that all 1000 of them are busy right now, but it should
indicate that 1000 simultaneous connections were needed at some point in
the life of the pool.

Have you looked at the connection pool statistics to see if its numbers
match what you're seeing?  If a pool has 1000 connections, then
getNumSuccessfulConnectionAttempts should return a value that is 1000
more than the sum of the values returned by the
getNumConnectionsClosedDefunct, getNumConnectionsClosedExpired, and
getNumConnectionsClosedUnneeded methods.



> My question: is there any recipe or configuration strategy to ensure the
> pooled connection count is a good match for the LDAP request
> requirements of the client?

Unless your client is doing some very weird things, you shouldn't need
more than one connection per application thread.  And the only scenarios
I can think of that might be able to allocate more than one connection
per thread would require you to check out and release connections
yourself, but it sounds like you're not doing that.



> We also ran a few simple tests that showed different connection build up
> with checked out LDAP connections, vs running requests against the pool.
> What is the preferred way to run LDAP requests for stable performance
> and optimal utilisation of the pooled connections?

I'm not sure why you would see any difference in the accumulation of
connections when you let the pool check out and release connections in
the course of processing an operation and when you check out and release
the connections for yourself.  Letting the pool do it for you enables
the potential for using additional functionality that you can't get when
checking out and restoring the connections for yourself (for example,
automatically retrying a failed operation on a newly-established
connection), and also simplifies your application code, so I would
recommend going with that approach.  But ultimately, if you have the
pool check out and release connections for you, then it should be using
exactly the same methods to check out and release connections that you
would use if you were doing it yourself.

Do you have any kind of reproducible test case that you could provide to
demonstrate the problem?  If not, would you be able to provide the code
that you're using to create and manage the connection pool (in
particular, the constructor you're using, along with any calls to setter
methods for customizing the pool behavior, like enabling retry, setting
a maximum connection age, configuring a health check, etc.)?  Feel free
to obscure or hide any sensitive information, since it's more about
understanding what calls you're making than exactly what arguments are
provided.



> 
> 
> Any suggestions or insights will be appreciated.
> 
> Thanks,
> 
> 
> Vladimir
> 

[ldap-sdk-discuss] LDAP connection pool behaviour

[Vladimir D. <vla...@co...>]

Hi,

I would like to report on some recently observed behaviour of the LDAP
connection pool in v3.3.1.

The setup looks like this:

8 LDAP clients, each on the node of a clustered web app.

Each LDAP client is configured with an LDAP connection pool:

* Initial number of connections: 0
* Max number of connections: 1024
* Max connection wait time: 500ms
* Max connection age: 0


LDAP requests are run against the pool, i.e. connections are not checked
out, then returned.


With this setup and the typical app load the number of available
connections settles to ~200. On several occasions however, when a new
LDAP client / app node is started, the pool is slow to create new
connections, settling to about 5 to 10, and leading to a degraded app
performance. To address this, the setting for the initial number of
connections was raised to 50. With this setup however, the pooled
connections immediately jumped to the max limit (~1000).

My question: is there any recipe or configuration strategy to ensure the
pooled connection count is a good match for the LDAP request
requirements of the client?

We also ran a few simple tests that showed different connection build up
with checked out LDAP connections, vs running requests against the pool.
What is the preferred way to run LDAP requests for stable performance
and optimal utilisation of the pooled connections?


Any suggestions or insights will be appreciated.

Thanks,


Vladimir
-- 
Vladimir Dzhuvinov

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 3.1.1

[Neil A. W. <nei...@un...>]

We have just released the UnboundID LDAP SDK for Java version 3.1.1, as
a minor update over the previous 3.1.0 release. The release notes,
available at https://docs.ldap.com/ldap-sdk/docs/release-notes.html,
contain an overview of the changes in this release.

New versions of the Standard Edition, Commercial Edition, and Minimal
Edition are available for download at
https://www.ldap.com/unboundid-ldap-sdk-for-java, from GitHub at
https://github.com/UnboundID/ldapsdk/releases/latest, and from
SourceForge at https://sourceforge.net/projects/ldap-sdk/. It is also
available in the Maven Central Repository.


Neil Wilson
Principal Engineer
UnboundID Corp.

Re: [ldap-sdk-discuss] Best approach to updating members of a group

[Lucas R. <lu...@me...>]

Neil,

As always, thank you for the very thorough response!

-lucas

> On Dec 16, 2015, at 2:07 PM, Neil A. Wilson <nei...@un...> wrote:
> 
> On 12/16/2015 12:35 PM, Lucas Rockwell wrote:
>> Hello,
>> 
>> When updating a group (regardless of the number of members, as it can be any size), is it better to use a list of Modification objects that are of type ADD and REMOVE (for just the added and removed members), or is it okay to use REPLACE (which then has the info for the entire group, which can be large). I assume the former, but I just wanted to do a sanity check.
>> 
>> Thank you.
>> 
>> -lucas
> 
> It is better to use the ADD modification type to add new members and the
> DELETE modification type to remove existing members.  There are a couple
> of potential problems with using the REPLACE modification type to
> explicitly set the desired membership:
> 
> - In the event that two clients are making a change to group membership
> at the same time, then the use of the REPLACE modification type could
> cause one client to undo the change made by the other client.  For
> example, let's say that I currently have a group with members A, B, and
> C.  Client one wants to add D as a new member, while client two wants to
> remove B as a member.  If this happens at about the same time, then both
> clients could see the current member list of A, B, and C and then the
> first one would send a REPLACE with A, B, C, and D while the second
> would send a replace with just A and C, and the resulting member list
> would be whichever of the two operations completed last.  On the other
> hand, if client one sent an ADD with member D and client two sent a
> DELETE with member B, then you would correctly end up with A, C, and D
> after both operations were processed, regardless of their order.
> 
> - An LDAP REPLACE modification type requires that you supply the entire
> new set of values in the request.  For a very large group (e.g., one
> with hundreds of thousands of members), this could result in a very
> large request, and some servers place an upper bound on the size of the
> request that they will accept from clients (as a way of protecting
> against the possibility of a malicious or buggy client trying to cause
> the server to allocate a huge amount of memory), and an attempt to send
> a request that is too large generally causes the server to terminate the
> client connection.
> 
> 
> Neil
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> ldap-sdk-discuss mailing list
> lda...@li...
> https://lists.sourceforge.net/lists/listinfo/ldap-sdk-discuss

Re: [ldap-sdk-discuss] Best approach to updating members of a group

[Neil A. W. <nei...@un...>]

On 12/16/2015 12:35 PM, Lucas Rockwell wrote:
> Hello,
> 
> When updating a group (regardless of the number of members, as it can be any size), is it better to use a list of Modification objects that are of type ADD and REMOVE (for just the added and removed members), or is it okay to use REPLACE (which then has the info for the entire group, which can be large). I assume the former, but I just wanted to do a sanity check.
> 
> Thank you.
> 
> -lucas

It is better to use the ADD modification type to add new members and the
DELETE modification type to remove existing members.  There are a couple
of potential problems with using the REPLACE modification type to
explicitly set the desired membership:

- In the event that two clients are making a change to group membership
at the same time, then the use of the REPLACE modification type could
cause one client to undo the change made by the other client.  For
example, let's say that I currently have a group with members A, B, and
C.  Client one wants to add D as a new member, while client two wants to
remove B as a member.  If this happens at about the same time, then both
clients could see the current member list of A, B, and C and then the
first one would send a REPLACE with A, B, C, and D while the second
would send a replace with just A and C, and the resulting member list
would be whichever of the two operations completed last.  On the other
hand, if client one sent an ADD with member D and client two sent a
DELETE with member B, then you would correctly end up with A, C, and D
after both operations were processed, regardless of their order.

- An LDAP REPLACE modification type requires that you supply the entire
new set of values in the request.  For a very large group (e.g., one
with hundreds of thousands of members), this could result in a very
large request, and some servers place an upper bound on the size of the
request that they will accept from clients (as a way of protecting
against the possibility of a malicious or buggy client trying to cause
the server to allocate a huge amount of memory), and an attempt to send
a request that is too large generally causes the server to terminate the
client connection.


Neil

[ldap-sdk-discuss] Best approach to updating members of a group

[Lucas R. <lu...@me...>]

Hello,

When updating a group (regardless of the number of members, as it can be any size), is it better to use a list of Modification objects that are of type ADD and REMOVE (for just the added and removed members), or is it okay to use REPLACE (which then has the info for the entire group, which can be large). I assume the former, but I just wanted to do a sanity check.

Thank you.

-lucas

[ldap-sdk-discuss] UnboundID LDAP SDK for Java 3.1.0

[Neil A. W. <nei...@un...>]

We have just released the UnboundID LDAP SDK for Java version 3.1.0,
including a number of new features, bug fixes, and improvements. The
release notes, available at
https://docs.ldap.com/ldap-sdk/docs/release-notes.html, contain an
overview of the changes in this release.

New versions of the Standard Edition, Commercial Edition, and Minimal
Edition are available for download at
https://www.ldap.com/unboundid-ldap-sdk-for-java, from GitHub at
https://github.com/UnboundID/ldapsdk/releases/latest, and from
SourceForge at https://sourceforge.net/projects/ldap-sdk/. It is also
available in the Maven Central Repository.


Neil Wilson
Principal Engineer
UnboundID Corp.

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[SINGH, H. K. (H. KUMAR) <him...@al...>]

Hello Neil,

Thank you for the excellent support!

I have all my queries on the Join operation, answered.

With Best Regards,
Himanshu


-----Original Message-----
From: nei...@un... [mailto:nei...@un...] 
Sent: Thursday, October 01, 2015 8:22 PM
To: lda...@li...; SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)
Subject: RE: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

Because you have multiple types of entries, there really isn't a good way to return only entries that are joined with all three types of entries.  The closest you can get is to set requireMatch to true, which will cause the server to only return entries that are joined with at least one other entry.  But it isn't possible to require joining with multiple matching entries.  You'll just have to look at the entries returned to see what they were joined with and ignore any that weren't joined with all three types.  A simple client-side optimization would be to ignore entries that aren't joined with at least three other entries.  If there are a lot of entries that are only joined with one or two but not all three types, then this will cause more data to be transferred over the network than you need, but it's still a pretty substantial savings over doing it without the join.

As far as handling searches that have the potential to match a large number of entries, the best thing to do is to use the simple paged results control as described in RFC 2696.  This control allows you to request that the server return entries in batches of a specified size, and each set of results will include a token that you can use to issue the same search but pick up where it left off.  The LDAP SDK supports this control, and the javadoc (available at https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/SimplePagedResultsControl.html) includes an example that demonstrates how to use it.


Neil


-----Original Message-----
From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
To: "Neil A. Wilson" <nei...@un...>, "lda...@li..." <lda...@li...>
Sent: Wed, 30 Sep 2015 11:20 PM
Subject: RE: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

Hello Neil,

This is exactly what I was looking for. Thank you.

It is now clear where to use a nested join and where to use a simple search request with a single join.
I could also use the tip on handling the possibly large number of search results.

I implemented the code as you suggested and it works fine.
The only problem I am left with now is "how to return ONLY those results that contain entries from ALL the constituent objects?"

Details:
I have a few cases where the join attribute's name is not the same in the dependent objects.
For example, we may have the join conditions as:
1.  Subscriber.cardNumber = bundle.subscriberNumber 2.  Subscriber.cardNumber = subscription.subNumber 3.  Subscriber.cardNumber = profile.subscriberNum

To handle the different attribute names, I changed the join rule as:

JoinRule joinRule = JoinRule.createORRule(
    			  JoinRule.createEqualityJoin("cardNumber", "subscriberNumber", false),
    			  JoinRule.createEqualityJoin("cardNumber", "subNumber", false),
			  JoinRule.createEqualityJoin("cardNumber", "subscriberNum", false));
    	

My requirement is to fetch ONLY those joined entries that contain entries from ALL the objects(Subscriber, Bundle, Subscription and Profile).
But with the curent code, I get even those joined entries that do not contain entries from one or more of the dependent objects.
I did try a few filters but nothing worked so far.

With Best Regards,
Himanshu

-----Original Message-----
From: Neil A. Wilson [mailto:nei...@un...]
Sent: Wednesday, September 30, 2015 1:30 PM
To: SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR); lda...@li...
Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

It's still not completely clear what you're asking, but it sounds like you're searching to retrieve a subscriber entry, and you want to join that with the associated bundle, subscription, and profile entries.
Further, it sounds like you've got an attribute (let's assume the attribute is cardNumber; card_number isn't a valid LDAP attribute name since underscores aren't allowed) in the subscriber entry whose value matches the subscriberNumber attribute in the bundle, subscription, and profile entries.

If that's the case, then it should be a pretty simple matter.  You shouldn't use a nested join for this because even though you want to join with three different kinds of entries, you want to join each of them using information contained the subscriber entry.  A nested join is primarily useful in the case where you have to join with other joined entries instead of joining with the original search result entry.

Here's some code to get you started.  Since you didn't provide me with all the details about the structure of the entries you're working with, you'll have to edit it as laid out in the comments.

    // Create a search request to retrieve subscriber entries.
    //
    // NOTE:  If this search will match a large number of entries,
    //        then you should probably use something like the simple
    //        paged results control to retrieve matching entries in
    //        batches rather than trying to have them all returned in
    //        a single search.  Or at least use a search result
    //        listener so that the client doesn't have to hold all of
    //        the matching entries in memory simultaneously.
    SearchRequest searchRequest = new SearchRequest(
         "ospobject=subscriber,dc=alcatel,dc=com", SearchScope.SUB,
         Filter.createPresenceFilter("cardNumber"),
         "name", "credit", "cardNumber");


    // Create a join rule that will match entries that have a
    // subscriberNumber value that is the same as the cardNumber
    // value from each entry that matches the search request.
    JoinRule joinRule = JoinRule.createEqualityJoin("cardNumber",
         "subscriberNumber", false);


    // Define the join base DN, which is where we will search for
    // the entries to be joined.  In this case, we want to join with
    // three different types of entries, and those entries exist in
    // different subtrees.  However, each of those subtrees is below
    // "dc=alcatel,dc=com", so we'll use that as the common search
    // base DN for the join processing.
    JoinBaseDN joinBaseDN =
         JoinBaseDN.createUseCustomBaseDN("dc=alcatel,dc=com");


    // Next, define a filter that will match only bundle,
    // subscription, and profile entries.  This may not be needed in
    // all cases, but it will be if there are other kinds of entries
    // that might have a subscriberNumber attribute that you don't
    // want to include in the join.  I don't know what the real
    // object class names you're using for bundle, subscriber, and
    // profile entries, so you should replace what I've used here
    // with the appropriate names.
    Filter additionalJoinFilter = Filter.createORFilter(
         Filter.createEqualityFilter("objectClass", "bundleOC"),
         Filter.createEqualityFilter("objectClass", "subscriptionOC"),
         Filter.createEqualityFilter("objectClass", "profileOC"));


    // Define the set of attributes that we want to be returned.
    // Since we're returning three different types of entries, then
    // we should include all attributes we want to get from all three
    // types of entries.  Also include the objectClass attribute so
    // that we can use that to determine the type of each joined
    // entry.
    String[] attributesInJoinedEntries =
    {
      "bundleName",
      "bundleCredit",
      "subscriptionName",
      "subscriptionCredit",
      "profileName",
      "objectClass"
    };


    // Define the behavior that the search should use for entries
    // that match the search criteria (in this case, for entries that
    // are subscribers that have a cardNumber) but for which there
    // aren't any associated bundle, subscription, or profile
    // entries.  A requireMatch value of false indicates that we
    // should return matching subscriber entries even if there aren't
    // any associated bundle, subscription, or profile entries.  A
    // requireMatch value of true indicates that we should only
    // return subscriber entries that are joined with at least one
    // bundle, subscription, or profile.
    boolean requireMatch = false;


    // Create the join request value and use that to create the join
    // request control that is assigned to the search.
    JoinRequestValue joinValue = new JoinRequestValue(
         joinRule,
         joinBaseDN,
         SearchScope.SUB,
         DereferencePolicy.NEVER,
         0, // No size limit
         additionalJoinFilter,
         attributesInJoinedEntries,
         requireMatch,
         null); // No nested join.
    searchRequest.addControl(new JoinRequestControl(joinValue));


    // Process the search and iterate through the matching entries.
    SearchResult searchResult = connection.search(searchRequest);
    for (SearchResultEntry subscriberEntry :
         searchResult.getSearchEntries())
    {
      // Get the attributes we want from the subscriber entry.
      String subscriberName =
           subscriberEntry.getAttributeValue("subscriberName");
      String subscriberCredit =
           subscriberEntry.getAttributeValue("subscriberCredit");
      String subscriberCardNumber =
           subscriberEntry.getAttributeValue("cardNumber");


      // Get the join result that will link the subscriber entry with
      // any associated bundle, subscription, and/or profile entries.
      JoinResultControl joinResultControl =
           JoinResultControl.get(subscriberEntry);
      if (joinResultControl != null)
      {
        for (JoinedEntry joinedEntry :
             joinResultControl.getJoinResults())
        {
          if (joinedEntry.hasAttributeValue("objectClass",
               "bundleOC"))
          {
            // It's a bundle entry.
            String bundleName =
                 joinedEntry.getAttributeValue("bundleName");
            String bundleCredit =
                 joinedEntry.getAttributeValue("bundleCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "subscriptionOC"))
          {
            // It's a subscription entry.
            String subscriptionName =
                 joinedEntry.getAttributeValue("subscriptionName");
            String subscriptionCredit =
                 joinedEntry.getAttributeValue("subscriptionCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "profileOC"))
          {
            // It's a profile entry.
            String profileName =
                 joinedEntry.getAttributeValue("profileName");
          }
        }
      }
    }




On 09/29/2015 10:22 AM, SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR) wrote:
> Hello Neil,
> 
> 
> 
> Thank you for your response and pardon me for the non-technical jargon I used. I will be as precise as possible in this text.
> 
> 
> 
> We have to replace an RDBMS database(specifically Oracle) with LDAP; hence the non-LDAP terms. Please excuse me for that too.
> 
> The risks, limitations and advantages are well understood; the decision has been made and design is in progress.
> 
> 
> 
> THE JOIN PROBLEM GENERALIZED WITH AN EXAMPLE:
> 
> 
> 
> - We have 4 objects, each made up of a few attributes and represented by a unique DN.
> 
> 
> 
> Dn: ospobject=subscriber,dc=alcatel,dc=com
> 
> 
> Card_number
> 
> 
> Name
> 
> 
> Credit
> 
> 
> 
> 
> Dn: ospobject=bundle,dc=alcatel,dc=com
> 
> 
> Bundle_name
> 
> 
> Bundle_credit
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=subscription,dc=alcatel,dc=com
> 
> 
> Subscription_name
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=profile,dc=alcatel,dc=com
> 
> 
> Profile_name
> 
> 
> Profile_validity
> 
> 
> Subscriber_number
> 
> 
> 
> 
> **there are a huge number of entries in these objects. It is not possible to combine all these tables in a single table.
> 
> 
> 
> - Our objective is to fetch all of a subscriber’s information, including all his bundles, subscriptions and profile in a single search.
> 
>       Our JOIN conditions are:
> 
> 1.  Subscriber.card_number = bundle.Subscriber_number
> 
> 2.  Subscriber.card_number = subscription.Subscriber_number
> 
> 3.  Subscriber.card_number = profile.Subscriber_number
> 
> 
> 
> 
> 
> 
> 
> What we have tried:
> 
> We came across the documentation of the commercial version of the LDAP SDK. We are trying to see if the JoinRequestControl can solve our problem.
> 
> Below is an abstract of what we have tried so far:
> 
> 
> 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------
> //The attributes to be fetched
> String args_subscriber[]  ={"name","credit",”card_number”};                //attributes to be fetched from the subscriber object
> String args_bundle[]      ={"Bundle_name","Bundle_credit"};                //attributes to be fetched from the bundle object
> 
> String args_subscription[]={"Subscription_name","Subscription_credit"};    //attributes to be fetched from the subscription object
> 
> String args_profile[]     ={"Profile_name”};                               //attributes to be fetched from the profile object
> 
> 
> 
> 
> 
> //Define the SearchRequest on the ‘Subscriber’ object
> 
> SearchRequest searchRequest = new SearchRequest(“ospobject=subscriber,dc=alcatel,dc=com”, SearchScope.SUB, Filter.create("card_number=*"),args_subscriber); //the ‘subscriber’ DN.
> 
> .
> 
> .
> 
> .
> 
> 
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ 
> and ‘profile’ objects JoinRequestValue nestedJoinval2 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, 
> ”subscriber_number", false),
> 
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=profile,dc=alcatel,dc=com"), //the ‘profile’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, null);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ 
> and ‘subscription’ objects
> 
> //Also add the nested JoinRequestValue defined above, to this 
> JoinRequestValue JoinRequestValue nestedJoinval1 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, 
> ”subscriber_number", false),
> 
>                             JoinBaseDN.createUseCustomBaseDN("ospobject=subscription,dc=alcatel,dc=com"), //the ‘subscription’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, nestedJoinval2);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ 
> and ‘bundle’ objects
> 
> //Also add the JoinRequestControl to the SearchRequest 
> searchRequest.addControl(new JoinRequestControl(new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number", "subscriber_number", false),
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=bundle,dc=alcatel,dc=com "), //the ‘bundle’ object DN.
>                      SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                      args_bundle,
> 
>                            true, nestedJoinval1)));
> 
> 
> 
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> ----------------------------------
> 
> 
> 
> 
> 
> The intention of the nested join is to join the subscriber and subscription objects.
> 
> But it seems that the nested join works only on the DN specified in its corresponding parent join.
> 
> 
> 
> I can’t find a way of specifying the nested join to work on the Join results of the parent join.
> 
> 
> 
> Is my understanding correct?
> 
> Do I have a way out?
> 
> 
> 
> 
> 
> 
> 
> With Best Regards,
> 
> Himanshu
> 
> 
> 
> -----Original Message-----
> 
> From: nei...@un... [mailto:nei...@un...]
> 
> Sent: Monday, September 28, 2015 7:43 PM
> 
> To: lda...@li...; SINGH, HIMANSHU KUMAR 
> (HIMANSHU KUMAR)
> 
> Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?
> 
> 
> 
> 
> 
> Neil
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" 
> <him...@al...>
> 
> To: "lda...@li..." 
> <lda...@li...>
> 
> Sent: Mon, 28 Sep 2015 9:05 AM
> 
> Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> Hello LDAP SDK teams,
> 
> 
> 
> I am trying to implement a multi-join using the SDK.
> 
> My problem is that I have a "master" entry with 4 different attributes.
> 
> All 4 of them refer to the PK attribute of 4 other tables.
> 
> These other tables are not directly related to each other.
> 
> 
> 
> I have to implement a join on all 5 tables in a single search request.
> 
> 
> 
> The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.
> 
> 
> 
> Any ideas??
> 
> 
> 
> 
> 
> -    Himanshu
> 
> 
> 
> 

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[<nei...@un...>]

Because you have multiple types of entries, there really isn't a good way to return only entries that are joined with all three types of entries.  The closest you can get is to set requireMatch to true, which will cause the server to only return entries that are joined with at least one other entry.  But it isn't possible to require joining with multiple matching entries.  You'll just have to look at the entries returned to see what they were joined with and ignore any that weren't joined with all three types.  A simple client-side optimization would be to ignore entries that aren't joined with at least three other entries.  If there are a lot of entries that are only joined with one or two but not all three types, then this will cause more data to be transferred over the network than you need, but it's still a pretty substantial savings over doing it without the join.

As far as handling searches that have the potential to match a large number of entries, the best thing to do is to use the simple paged results control as described in RFC 2696.  This control allows you to request that the server return entries in batches of a specified size, and each set of results will include a token that you can use to issue the same search but pick up where it left off.  The LDAP SDK supports this control, and the javadoc (available at https://docs.ldap.com/ldap-sdk/docs/javadoc/index.html?com/unboundid/ldap/sdk/controls/SimplePagedResultsControl.html) includes an example that demonstrates how to use it.


Neil


-----Original Message-----
From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
To: "Neil A. Wilson" <nei...@un...>, "lda...@li..." <lda...@li...>
Sent: Wed, 30 Sep 2015 11:20 PM
Subject: RE: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

Hello Neil,

This is exactly what I was looking for. Thank you.

It is now clear where to use a nested join and where to use a simple search request with a single join.
I could also use the tip on handling the possibly large number of search results.

I implemented the code as you suggested and it works fine.
The only problem I am left with now is "how to return ONLY those results that contain entries from ALL the constituent objects?"

Details:
I have a few cases where the join attribute's name is not the same in the dependent objects.
For example, we may have the join conditions as:
1.  Subscriber.cardNumber = bundle.subscriberNumber
2.  Subscriber.cardNumber = subscription.subNumber
3.  Subscriber.cardNumber = profile.subscriberNum

To handle the different attribute names, I changed the join rule as:

JoinRule joinRule = JoinRule.createORRule(
    			  JoinRule.createEqualityJoin("cardNumber", "subscriberNumber", false),
    			  JoinRule.createEqualityJoin("cardNumber", "subNumber", false),
			  JoinRule.createEqualityJoin("cardNumber", "subscriberNum", false));
    	

My requirement is to fetch ONLY those joined entries that contain entries from ALL the objects(Subscriber, Bundle, Subscription and Profile).
But with the curent code, I get even those joined entries that do not contain entries from one or more of the dependent objects.
I did try a few filters but nothing worked so far.

With Best Regards,
Himanshu

-----Original Message-----
From: Neil A. Wilson [mailto:nei...@un...] 
Sent: Wednesday, September 30, 2015 1:30 PM
To: SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR); lda...@li...
Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

It's still not completely clear what you're asking, but it sounds like
you're searching to retrieve a subscriber entry, and you want to join
that with the associated bundle, subscription, and profile entries.
Further, it sounds like you've got an attribute (let's assume the
attribute is cardNumber; card_number isn't a valid LDAP attribute name
since underscores aren't allowed) in the subscriber entry whose value
matches the subscriberNumber attribute in the bundle, subscription, and
profile entries.

If that's the case, then it should be a pretty simple matter.  You
shouldn't use a nested join for this because even though you want to
join with three different kinds of entries, you want to join each of
them using information contained the subscriber entry.  A nested join is
primarily useful in the case where you have to join with other joined
entries instead of joining with the original search result entry.

Here's some code to get you started.  Since you didn't provide me with
all the details about the structure of the entries you're working with,
you'll have to edit it as laid out in the comments.

    // Create a search request to retrieve subscriber entries.
    //
    // NOTE:  If this search will match a large number of entries,
    //        then you should probably use something like the simple
    //        paged results control to retrieve matching entries in
    //        batches rather than trying to have them all returned in
    //        a single search.  Or at least use a search result
    //        listener so that the client doesn't have to hold all of
    //        the matching entries in memory simultaneously.
    SearchRequest searchRequest = new SearchRequest(
         "ospobject=subscriber,dc=alcatel,dc=com", SearchScope.SUB,
         Filter.createPresenceFilter("cardNumber"),
         "name", "credit", "cardNumber");


    // Create a join rule that will match entries that have a
    // subscriberNumber value that is the same as the cardNumber
    // value from each entry that matches the search request.
    JoinRule joinRule = JoinRule.createEqualityJoin("cardNumber",
         "subscriberNumber", false);


    // Define the join base DN, which is where we will search for
    // the entries to be joined.  In this case, we want to join with
    // three different types of entries, and those entries exist in
    // different subtrees.  However, each of those subtrees is below
    // "dc=alcatel,dc=com", so we'll use that as the common search
    // base DN for the join processing.
    JoinBaseDN joinBaseDN =
         JoinBaseDN.createUseCustomBaseDN("dc=alcatel,dc=com");


    // Next, define a filter that will match only bundle,
    // subscription, and profile entries.  This may not be needed in
    // all cases, but it will be if there are other kinds of entries
    // that might have a subscriberNumber attribute that you don't
    // want to include in the join.  I don't know what the real
    // object class names you're using for bundle, subscriber, and
    // profile entries, so you should replace what I've used here
    // with the appropriate names.
    Filter additionalJoinFilter = Filter.createORFilter(
         Filter.createEqualityFilter("objectClass", "bundleOC"),
         Filter.createEqualityFilter("objectClass", "subscriptionOC"),
         Filter.createEqualityFilter("objectClass", "profileOC"));


    // Define the set of attributes that we want to be returned.
    // Since we're returning three different types of entries, then
    // we should include all attributes we want to get from all three
    // types of entries.  Also include the objectClass attribute so
    // that we can use that to determine the type of each joined
    // entry.
    String[] attributesInJoinedEntries =
    {
      "bundleName",
      "bundleCredit",
      "subscriptionName",
      "subscriptionCredit",
      "profileName",
      "objectClass"
    };


    // Define the behavior that the search should use for entries
    // that match the search criteria (in this case, for entries that
    // are subscribers that have a cardNumber) but for which there
    // aren't any associated bundle, subscription, or profile
    // entries.  A requireMatch value of false indicates that we
    // should return matching subscriber entries even if there aren't
    // any associated bundle, subscription, or profile entries.  A
    // requireMatch value of true indicates that we should only
    // return subscriber entries that are joined with at least one
    // bundle, subscription, or profile.
    boolean requireMatch = false;


    // Create the join request value and use that to create the join
    // request control that is assigned to the search.
    JoinRequestValue joinValue = new JoinRequestValue(
         joinRule,
         joinBaseDN,
         SearchScope.SUB,
         DereferencePolicy.NEVER,
         0, // No size limit
         additionalJoinFilter,
         attributesInJoinedEntries,
         requireMatch,
         null); // No nested join.
    searchRequest.addControl(new JoinRequestControl(joinValue));


    // Process the search and iterate through the matching entries.
    SearchResult searchResult = connection.search(searchRequest);
    for (SearchResultEntry subscriberEntry :
         searchResult.getSearchEntries())
    {
      // Get the attributes we want from the subscriber entry.
      String subscriberName =
           subscriberEntry.getAttributeValue("subscriberName");
      String subscriberCredit =
           subscriberEntry.getAttributeValue("subscriberCredit");
      String subscriberCardNumber =
           subscriberEntry.getAttributeValue("cardNumber");


      // Get the join result that will link the subscriber entry with
      // any associated bundle, subscription, and/or profile entries.
      JoinResultControl joinResultControl =
           JoinResultControl.get(subscriberEntry);
      if (joinResultControl != null)
      {
        for (JoinedEntry joinedEntry :
             joinResultControl.getJoinResults())
        {
          if (joinedEntry.hasAttributeValue("objectClass",
               "bundleOC"))
          {
            // It's a bundle entry.
            String bundleName =
                 joinedEntry.getAttributeValue("bundleName");
            String bundleCredit =
                 joinedEntry.getAttributeValue("bundleCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "subscriptionOC"))
          {
            // It's a subscription entry.
            String subscriptionName =
                 joinedEntry.getAttributeValue("subscriptionName");
            String subscriptionCredit =
                 joinedEntry.getAttributeValue("subscriptionCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "profileOC"))
          {
            // It's a profile entry.
            String profileName =
                 joinedEntry.getAttributeValue("profileName");
          }
        }
      }
    }




On 09/29/2015 10:22 AM, SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR) wrote:
> Hello Neil,
> 
> 
> 
> Thank you for your response and pardon me for the non-technical jargon I used. I will be as precise as possible in this text.
> 
> 
> 
> We have to replace an RDBMS database(specifically Oracle) with LDAP; hence the non-LDAP terms. Please excuse me for that too.
> 
> The risks, limitations and advantages are well understood; the decision has been made and design is in progress.
> 
> 
> 
> THE JOIN PROBLEM GENERALIZED WITH AN EXAMPLE:
> 
> 
> 
> - We have 4 objects, each made up of a few attributes and represented by a unique DN.
> 
> 
> 
> Dn: ospobject=subscriber,dc=alcatel,dc=com
> 
> 
> Card_number
> 
> 
> Name
> 
> 
> Credit
> 
> 
> 
> 
> Dn: ospobject=bundle,dc=alcatel,dc=com
> 
> 
> Bundle_name
> 
> 
> Bundle_credit
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=subscription,dc=alcatel,dc=com
> 
> 
> Subscription_name
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=profile,dc=alcatel,dc=com
> 
> 
> Profile_name
> 
> 
> Profile_validity
> 
> 
> Subscriber_number
> 
> 
> 
> 
> **there are a huge number of entries in these objects. It is not possible to combine all these tables in a single table.
> 
> 
> 
> - Our objective is to fetch all of a subscriber’s information, including all his bundles, subscriptions and profile in a single search.
> 
>       Our JOIN conditions are:
> 
> 1.  Subscriber.card_number = bundle.Subscriber_number
> 
> 2.  Subscriber.card_number = subscription.Subscriber_number
> 
> 3.  Subscriber.card_number = profile.Subscriber_number
> 
> 
> 
> 
> 
> 
> 
> What we have tried:
> 
> We came across the documentation of the commercial version of the LDAP SDK. We are trying to see if the JoinRequestControl can solve our problem.
> 
> Below is an abstract of what we have tried so far:
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> //The attributes to be fetched
> String args_subscriber[]  ={"name","credit",”card_number”};                //attributes to be fetched from the subscriber object
> String args_bundle[]      ={"Bundle_name","Bundle_credit"};                //attributes to be fetched from the bundle object
> 
> String args_subscription[]={"Subscription_name","Subscription_credit"};    //attributes to be fetched from the subscription object
> 
> String args_profile[]     ={"Profile_name”};                               //attributes to be fetched from the profile object
> 
> 
> 
> 
> 
> //Define the SearchRequest on the ‘Subscriber’ object
> 
> SearchRequest searchRequest = new SearchRequest(“ospobject=subscriber,dc=alcatel,dc=com”, SearchScope.SUB, Filter.create("card_number=*"),args_subscriber); //the ‘subscriber’ DN.
> 
> .
> 
> .
> 
> .
> 
> 
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘profile’ objects
> JoinRequestValue nestedJoinval2 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=profile,dc=alcatel,dc=com"), //the ‘profile’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, null);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘subscription’ objects
> 
> //Also add the nested JoinRequestValue defined above, to this JoinRequestValue
> JoinRequestValue nestedJoinval1 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                             JoinBaseDN.createUseCustomBaseDN("ospobject=subscription,dc=alcatel,dc=com"), //the ‘subscription’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, nestedJoinval2);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘bundle’ objects
> 
> //Also add the JoinRequestControl to the SearchRequest
> searchRequest.addControl(new JoinRequestControl(new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number", "subscriber_number", false),
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=bundle,dc=alcatel,dc=com "), //the ‘bundle’ object DN.
>                      SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                      args_bundle,
> 
>                            true, nestedJoinval1)));
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> The intention of the nested join is to join the subscriber and subscription objects.
> 
> But it seems that the nested join works only on the DN specified in its corresponding parent join.
> 
> 
> 
> I can’t find a way of specifying the nested join to work on the Join results of the parent join.
> 
> 
> 
> Is my understanding correct?
> 
> Do I have a way out?
> 
> 
> 
> 
> 
> 
> 
> With Best Regards,
> 
> Himanshu
> 
> 
> 
> -----Original Message-----
> 
> From: nei...@un... [mailto:nei...@un...]
> 
> Sent: Monday, September 28, 2015 7:43 PM
> 
> To: lda...@li...; SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)
> 
> Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?
> 
> 
> 
> 
> 
> Neil
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
> 
> To: "lda...@li..." <lda...@li...>
> 
> Sent: Mon, 28 Sep 2015 9:05 AM
> 
> Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> Hello LDAP SDK teams,
> 
> 
> 
> I am trying to implement a multi-join using the SDK.
> 
> My problem is that I have a "master" entry with 4 different attributes.
> 
> All 4 of them refer to the PK attribute of 4 other tables.
> 
> These other tables are not directly related to each other.
> 
> 
> 
> I have to implement a join on all 5 tables in a single search request.
> 
> 
> 
> The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.
> 
> 
> 
> Any ideas??
> 
> 
> 
> 
> 
> -    Himanshu
> 
> 
> 
> 

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[SINGH, H. K. (H. KUMAR) <him...@al...>]

Hello Neil,

This is exactly what I was looking for. Thank you.

It is now clear where to use a nested join and where to use a simple search request with a single join.
I could also use the tip on handling the possibly large number of search results.

I implemented the code as you suggested and it works fine.
The only problem I am left with now is "how to return ONLY those results that contain entries from ALL the constituent objects?"

Details:
I have a few cases where the join attribute's name is not the same in the dependent objects.
For example, we may have the join conditions as:
1.  Subscriber.cardNumber = bundle.subscriberNumber
2.  Subscriber.cardNumber = subscription.subNumber
3.  Subscriber.cardNumber = profile.subscriberNum

To handle the different attribute names, I changed the join rule as:

JoinRule joinRule = JoinRule.createORRule(
    			  JoinRule.createEqualityJoin("cardNumber", "subscriberNumber", false),
    			  JoinRule.createEqualityJoin("cardNumber", "subNumber", false),
			  JoinRule.createEqualityJoin("cardNumber", "subscriberNum", false));
    	

My requirement is to fetch ONLY those joined entries that contain entries from ALL the objects(Subscriber, Bundle, Subscription and Profile).
But with the curent code, I get even those joined entries that do not contain entries from one or more of the dependent objects.
I did try a few filters but nothing worked so far.

With Best Regards,
Himanshu

-----Original Message-----
From: Neil A. Wilson [mailto:nei...@un...] 
Sent: Wednesday, September 30, 2015 1:30 PM
To: SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR); lda...@li...
Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

It's still not completely clear what you're asking, but it sounds like
you're searching to retrieve a subscriber entry, and you want to join
that with the associated bundle, subscription, and profile entries.
Further, it sounds like you've got an attribute (let's assume the
attribute is cardNumber; card_number isn't a valid LDAP attribute name
since underscores aren't allowed) in the subscriber entry whose value
matches the subscriberNumber attribute in the bundle, subscription, and
profile entries.

If that's the case, then it should be a pretty simple matter.  You
shouldn't use a nested join for this because even though you want to
join with three different kinds of entries, you want to join each of
them using information contained the subscriber entry.  A nested join is
primarily useful in the case where you have to join with other joined
entries instead of joining with the original search result entry.

Here's some code to get you started.  Since you didn't provide me with
all the details about the structure of the entries you're working with,
you'll have to edit it as laid out in the comments.

    // Create a search request to retrieve subscriber entries.
    //
    // NOTE:  If this search will match a large number of entries,
    //        then you should probably use something like the simple
    //        paged results control to retrieve matching entries in
    //        batches rather than trying to have them all returned in
    //        a single search.  Or at least use a search result
    //        listener so that the client doesn't have to hold all of
    //        the matching entries in memory simultaneously.
    SearchRequest searchRequest = new SearchRequest(
         "ospobject=subscriber,dc=alcatel,dc=com", SearchScope.SUB,
         Filter.createPresenceFilter("cardNumber"),
         "name", "credit", "cardNumber");


    // Create a join rule that will match entries that have a
    // subscriberNumber value that is the same as the cardNumber
    // value from each entry that matches the search request.
    JoinRule joinRule = JoinRule.createEqualityJoin("cardNumber",
         "subscriberNumber", false);


    // Define the join base DN, which is where we will search for
    // the entries to be joined.  In this case, we want to join with
    // three different types of entries, and those entries exist in
    // different subtrees.  However, each of those subtrees is below
    // "dc=alcatel,dc=com", so we'll use that as the common search
    // base DN for the join processing.
    JoinBaseDN joinBaseDN =
         JoinBaseDN.createUseCustomBaseDN("dc=alcatel,dc=com");


    // Next, define a filter that will match only bundle,
    // subscription, and profile entries.  This may not be needed in
    // all cases, but it will be if there are other kinds of entries
    // that might have a subscriberNumber attribute that you don't
    // want to include in the join.  I don't know what the real
    // object class names you're using for bundle, subscriber, and
    // profile entries, so you should replace what I've used here
    // with the appropriate names.
    Filter additionalJoinFilter = Filter.createORFilter(
         Filter.createEqualityFilter("objectClass", "bundleOC"),
         Filter.createEqualityFilter("objectClass", "subscriptionOC"),
         Filter.createEqualityFilter("objectClass", "profileOC"));


    // Define the set of attributes that we want to be returned.
    // Since we're returning three different types of entries, then
    // we should include all attributes we want to get from all three
    // types of entries.  Also include the objectClass attribute so
    // that we can use that to determine the type of each joined
    // entry.
    String[] attributesInJoinedEntries =
    {
      "bundleName",
      "bundleCredit",
      "subscriptionName",
      "subscriptionCredit",
      "profileName",
      "objectClass"
    };


    // Define the behavior that the search should use for entries
    // that match the search criteria (in this case, for entries that
    // are subscribers that have a cardNumber) but for which there
    // aren't any associated bundle, subscription, or profile
    // entries.  A requireMatch value of false indicates that we
    // should return matching subscriber entries even if there aren't
    // any associated bundle, subscription, or profile entries.  A
    // requireMatch value of true indicates that we should only
    // return subscriber entries that are joined with at least one
    // bundle, subscription, or profile.
    boolean requireMatch = false;


    // Create the join request value and use that to create the join
    // request control that is assigned to the search.
    JoinRequestValue joinValue = new JoinRequestValue(
         joinRule,
         joinBaseDN,
         SearchScope.SUB,
         DereferencePolicy.NEVER,
         0, // No size limit
         additionalJoinFilter,
         attributesInJoinedEntries,
         requireMatch,
         null); // No nested join.
    searchRequest.addControl(new JoinRequestControl(joinValue));


    // Process the search and iterate through the matching entries.
    SearchResult searchResult = connection.search(searchRequest);
    for (SearchResultEntry subscriberEntry :
         searchResult.getSearchEntries())
    {
      // Get the attributes we want from the subscriber entry.
      String subscriberName =
           subscriberEntry.getAttributeValue("subscriberName");
      String subscriberCredit =
           subscriberEntry.getAttributeValue("subscriberCredit");
      String subscriberCardNumber =
           subscriberEntry.getAttributeValue("cardNumber");


      // Get the join result that will link the subscriber entry with
      // any associated bundle, subscription, and/or profile entries.
      JoinResultControl joinResultControl =
           JoinResultControl.get(subscriberEntry);
      if (joinResultControl != null)
      {
        for (JoinedEntry joinedEntry :
             joinResultControl.getJoinResults())
        {
          if (joinedEntry.hasAttributeValue("objectClass",
               "bundleOC"))
          {
            // It's a bundle entry.
            String bundleName =
                 joinedEntry.getAttributeValue("bundleName");
            String bundleCredit =
                 joinedEntry.getAttributeValue("bundleCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "subscriptionOC"))
          {
            // It's a subscription entry.
            String subscriptionName =
                 joinedEntry.getAttributeValue("subscriptionName");
            String subscriptionCredit =
                 joinedEntry.getAttributeValue("subscriptionCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "profileOC"))
          {
            // It's a profile entry.
            String profileName =
                 joinedEntry.getAttributeValue("profileName");
          }
        }
      }
    }




On 09/29/2015 10:22 AM, SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR) wrote:
> Hello Neil,
> 
> 
> 
> Thank you for your response and pardon me for the non-technical jargon I used. I will be as precise as possible in this text.
> 
> 
> 
> We have to replace an RDBMS database(specifically Oracle) with LDAP; hence the non-LDAP terms. Please excuse me for that too.
> 
> The risks, limitations and advantages are well understood; the decision has been made and design is in progress.
> 
> 
> 
> THE JOIN PROBLEM GENERALIZED WITH AN EXAMPLE:
> 
> 
> 
> - We have 4 objects, each made up of a few attributes and represented by a unique DN.
> 
> 
> 
> Dn: ospobject=subscriber,dc=alcatel,dc=com
> 
> 
> Card_number
> 
> 
> Name
> 
> 
> Credit
> 
> 
> 
> 
> Dn: ospobject=bundle,dc=alcatel,dc=com
> 
> 
> Bundle_name
> 
> 
> Bundle_credit
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=subscription,dc=alcatel,dc=com
> 
> 
> Subscription_name
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=profile,dc=alcatel,dc=com
> 
> 
> Profile_name
> 
> 
> Profile_validity
> 
> 
> Subscriber_number
> 
> 
> 
> 
> **there are a huge number of entries in these objects. It is not possible to combine all these tables in a single table.
> 
> 
> 
> - Our objective is to fetch all of a subscriber’s information, including all his bundles, subscriptions and profile in a single search.
> 
>       Our JOIN conditions are:
> 
> 1.  Subscriber.card_number = bundle.Subscriber_number
> 
> 2.  Subscriber.card_number = subscription.Subscriber_number
> 
> 3.  Subscriber.card_number = profile.Subscriber_number
> 
> 
> 
> 
> 
> 
> 
> What we have tried:
> 
> We came across the documentation of the commercial version of the LDAP SDK. We are trying to see if the JoinRequestControl can solve our problem.
> 
> Below is an abstract of what we have tried so far:
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> //The attributes to be fetched
> String args_subscriber[]  ={"name","credit",”card_number”};                //attributes to be fetched from the subscriber object
> String args_bundle[]      ={"Bundle_name","Bundle_credit"};                //attributes to be fetched from the bundle object
> 
> String args_subscription[]={"Subscription_name","Subscription_credit"};    //attributes to be fetched from the subscription object
> 
> String args_profile[]     ={"Profile_name”};                               //attributes to be fetched from the profile object
> 
> 
> 
> 
> 
> //Define the SearchRequest on the ‘Subscriber’ object
> 
> SearchRequest searchRequest = new SearchRequest(“ospobject=subscriber,dc=alcatel,dc=com”, SearchScope.SUB, Filter.create("card_number=*"),args_subscriber); //the ‘subscriber’ DN.
> 
> .
> 
> .
> 
> .
> 
> 
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘profile’ objects
> JoinRequestValue nestedJoinval2 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=profile,dc=alcatel,dc=com"), //the ‘profile’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, null);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘subscription’ objects
> 
> //Also add the nested JoinRequestValue defined above, to this JoinRequestValue
> JoinRequestValue nestedJoinval1 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                             JoinBaseDN.createUseCustomBaseDN("ospobject=subscription,dc=alcatel,dc=com"), //the ‘subscription’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, nestedJoinval2);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘bundle’ objects
> 
> //Also add the JoinRequestControl to the SearchRequest
> searchRequest.addControl(new JoinRequestControl(new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number", "subscriber_number", false),
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=bundle,dc=alcatel,dc=com "), //the ‘bundle’ object DN.
>                      SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                      args_bundle,
> 
>                            true, nestedJoinval1)));
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> The intention of the nested join is to join the subscriber and subscription objects.
> 
> But it seems that the nested join works only on the DN specified in its corresponding parent join.
> 
> 
> 
> I can’t find a way of specifying the nested join to work on the Join results of the parent join.
> 
> 
> 
> Is my understanding correct?
> 
> Do I have a way out?
> 
> 
> 
> 
> 
> 
> 
> With Best Regards,
> 
> Himanshu
> 
> 
> 
> -----Original Message-----
> 
> From: nei...@un... [mailto:nei...@un...]
> 
> Sent: Monday, September 28, 2015 7:43 PM
> 
> To: lda...@li...; SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)
> 
> Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?
> 
> 
> 
> 
> 
> Neil
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
> 
> To: "lda...@li..." <lda...@li...>
> 
> Sent: Mon, 28 Sep 2015 9:05 AM
> 
> Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> Hello LDAP SDK teams,
> 
> 
> 
> I am trying to implement a multi-join using the SDK.
> 
> My problem is that I have a "master" entry with 4 different attributes.
> 
> All 4 of them refer to the PK attribute of 4 other tables.
> 
> These other tables are not directly related to each other.
> 
> 
> 
> I have to implement a join on all 5 tables in a single search request.
> 
> 
> 
> The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.
> 
> 
> 
> Any ideas??
> 
> 
> 
> 
> 
> -    Himanshu
> 
> 
> 
> 

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[Neil A. W. <nei...@un...>]

It's still not completely clear what you're asking, but it sounds like
you're searching to retrieve a subscriber entry, and you want to join
that with the associated bundle, subscription, and profile entries.
Further, it sounds like you've got an attribute (let's assume the
attribute is cardNumber; card_number isn't a valid LDAP attribute name
since underscores aren't allowed) in the subscriber entry whose value
matches the subscriberNumber attribute in the bundle, subscription, and
profile entries.

If that's the case, then it should be a pretty simple matter.  You
shouldn't use a nested join for this because even though you want to
join with three different kinds of entries, you want to join each of
them using information contained the subscriber entry.  A nested join is
primarily useful in the case where you have to join with other joined
entries instead of joining with the original search result entry.

Here's some code to get you started.  Since you didn't provide me with
all the details about the structure of the entries you're working with,
you'll have to edit it as laid out in the comments.

    // Create a search request to retrieve subscriber entries.
    //
    // NOTE:  If this search will match a large number of entries,
    //        then you should probably use something like the simple
    //        paged results control to retrieve matching entries in
    //        batches rather than trying to have them all returned in
    //        a single search.  Or at least use a search result
    //        listener so that the client doesn't have to hold all of
    //        the matching entries in memory simultaneously.
    SearchRequest searchRequest = new SearchRequest(
         "ospobject=subscriber,dc=alcatel,dc=com", SearchScope.SUB,
         Filter.createPresenceFilter("cardNumber"),
         "name", "credit", "cardNumber");


    // Create a join rule that will match entries that have a
    // subscriberNumber value that is the same as the cardNumber
    // value from each entry that matches the search request.
    JoinRule joinRule = JoinRule.createEqualityJoin("cardNumber",
         "subscriberNumber", false);


    // Define the join base DN, which is where we will search for
    // the entries to be joined.  In this case, we want to join with
    // three different types of entries, and those entries exist in
    // different subtrees.  However, each of those subtrees is below
    // "dc=alcatel,dc=com", so we'll use that as the common search
    // base DN for the join processing.
    JoinBaseDN joinBaseDN =
         JoinBaseDN.createUseCustomBaseDN("dc=alcatel,dc=com");


    // Next, define a filter that will match only bundle,
    // subscription, and profile entries.  This may not be needed in
    // all cases, but it will be if there are other kinds of entries
    // that might have a subscriberNumber attribute that you don't
    // want to include in the join.  I don't know what the real
    // object class names you're using for bundle, subscriber, and
    // profile entries, so you should replace what I've used here
    // with the appropriate names.
    Filter additionalJoinFilter = Filter.createORFilter(
         Filter.createEqualityFilter("objectClass", "bundleOC"),
         Filter.createEqualityFilter("objectClass", "subscriptionOC"),
         Filter.createEqualityFilter("objectClass", "profileOC"));


    // Define the set of attributes that we want to be returned.
    // Since we're returning three different types of entries, then
    // we should include all attributes we want to get from all three
    // types of entries.  Also include the objectClass attribute so
    // that we can use that to determine the type of each joined
    // entry.
    String[] attributesInJoinedEntries =
    {
      "bundleName",
      "bundleCredit",
      "subscriptionName",
      "subscriptionCredit",
      "profileName",
      "objectClass"
    };


    // Define the behavior that the search should use for entries
    // that match the search criteria (in this case, for entries that
    // are subscribers that have a cardNumber) but for which there
    // aren't any associated bundle, subscription, or profile
    // entries.  A requireMatch value of false indicates that we
    // should return matching subscriber entries even if there aren't
    // any associated bundle, subscription, or profile entries.  A
    // requireMatch value of true indicates that we should only
    // return subscriber entries that are joined with at least one
    // bundle, subscription, or profile.
    boolean requireMatch = false;


    // Create the join request value and use that to create the join
    // request control that is assigned to the search.
    JoinRequestValue joinValue = new JoinRequestValue(
         joinRule,
         joinBaseDN,
         SearchScope.SUB,
         DereferencePolicy.NEVER,
         0, // No size limit
         additionalJoinFilter,
         attributesInJoinedEntries,
         requireMatch,
         null); // No nested join.
    searchRequest.addControl(new JoinRequestControl(joinValue));


    // Process the search and iterate through the matching entries.
    SearchResult searchResult = connection.search(searchRequest);
    for (SearchResultEntry subscriberEntry :
         searchResult.getSearchEntries())
    {
      // Get the attributes we want from the subscriber entry.
      String subscriberName =
           subscriberEntry.getAttributeValue("subscriberName");
      String subscriberCredit =
           subscriberEntry.getAttributeValue("subscriberCredit");
      String subscriberCardNumber =
           subscriberEntry.getAttributeValue("cardNumber");


      // Get the join result that will link the subscriber entry with
      // any associated bundle, subscription, and/or profile entries.
      JoinResultControl joinResultControl =
           JoinResultControl.get(subscriberEntry);
      if (joinResultControl != null)
      {
        for (JoinedEntry joinedEntry :
             joinResultControl.getJoinResults())
        {
          if (joinedEntry.hasAttributeValue("objectClass",
               "bundleOC"))
          {
            // It's a bundle entry.
            String bundleName =
                 joinedEntry.getAttributeValue("bundleName");
            String bundleCredit =
                 joinedEntry.getAttributeValue("bundleCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "subscriptionOC"))
          {
            // It's a subscription entry.
            String subscriptionName =
                 joinedEntry.getAttributeValue("subscriptionName");
            String subscriptionCredit =
                 joinedEntry.getAttributeValue("subscriptionCredit");
          }
          else if (joinedEntry.hasAttributeValue("objectClass",
               "profileOC"))
          {
            // It's a profile entry.
            String profileName =
                 joinedEntry.getAttributeValue("profileName");
          }
        }
      }
    }




On 09/29/2015 10:22 AM, SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR) wrote:
> Hello Neil,
> 
> 
> 
> Thank you for your response and pardon me for the non-technical jargon I used. I will be as precise as possible in this text.
> 
> 
> 
> We have to replace an RDBMS database(specifically Oracle) with LDAP; hence the non-LDAP terms. Please excuse me for that too.
> 
> The risks, limitations and advantages are well understood; the decision has been made and design is in progress.
> 
> 
> 
> THE JOIN PROBLEM GENERALIZED WITH AN EXAMPLE:
> 
> 
> 
> - We have 4 objects, each made up of a few attributes and represented by a unique DN.
> 
> 
> 
> Dn: ospobject=subscriber,dc=alcatel,dc=com
> 
> 
> Card_number
> 
> 
> Name
> 
> 
> Credit
> 
> 
> 
> 
> Dn: ospobject=bundle,dc=alcatel,dc=com
> 
> 
> Bundle_name
> 
> 
> Bundle_credit
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=subscription,dc=alcatel,dc=com
> 
> 
> Subscription_name
> 
> 
> Expiry
> 
> 
> Subscriber_number
> 
> 
> 
> 
> Dn: ospobject=profile,dc=alcatel,dc=com
> 
> 
> Profile_name
> 
> 
> Profile_validity
> 
> 
> Subscriber_number
> 
> 
> 
> 
> **there are a huge number of entries in these objects. It is not possible to combine all these tables in a single table.
> 
> 
> 
> - Our objective is to fetch all of a subscriber’s information, including all his bundles, subscriptions and profile in a single search.
> 
>       Our JOIN conditions are:
> 
> 1.  Subscriber.card_number = bundle.Subscriber_number
> 
> 2.  Subscriber.card_number = subscription.Subscriber_number
> 
> 3.  Subscriber.card_number = profile.Subscriber_number
> 
> 
> 
> 
> 
> 
> 
> What we have tried:
> 
> We came across the documentation of the commercial version of the LDAP SDK. We are trying to see if the JoinRequestControl can solve our problem.
> 
> Below is an abstract of what we have tried so far:
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> //The attributes to be fetched
> String args_subscriber[]  ={"name","credit",”card_number”};                //attributes to be fetched from the subscriber object
> String args_bundle[]      ={"Bundle_name","Bundle_credit"};                //attributes to be fetched from the bundle object
> 
> String args_subscription[]={"Subscription_name","Subscription_credit"};    //attributes to be fetched from the subscription object
> 
> String args_profile[]     ={"Profile_name”};                               //attributes to be fetched from the profile object
> 
> 
> 
> 
> 
> //Define the SearchRequest on the ‘Subscriber’ object
> 
> SearchRequest searchRequest = new SearchRequest(“ospobject=subscriber,dc=alcatel,dc=com”, SearchScope.SUB, Filter.create("card_number=*"),args_subscriber); //the ‘subscriber’ DN.
> 
> .
> 
> .
> 
> .
> 
> 
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘profile’ objects
> JoinRequestValue nestedJoinval2 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=profile,dc=alcatel,dc=com"), //the ‘profile’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, null);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘subscription’ objects
> 
> //Also add the nested JoinRequestValue defined above, to this JoinRequestValue
> JoinRequestValue nestedJoinval1 = new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),
> 
>                             JoinBaseDN.createUseCustomBaseDN("ospobject=subscription,dc=alcatel,dc=com"), //the ‘subscription’ object DN.
>                            SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                            args_subscription,
> 
>                            true, nestedJoinval2);
> 
> .
> 
> .
> 
> .
> 
> //define the nested JoinRequestValue for the join between ‘subscriber’ and ‘bundle’ objects
> 
> //Also add the JoinRequestControl to the SearchRequest
> searchRequest.addControl(new JoinRequestControl(new JoinRequestValue(
>                            JoinRule.createEqualityJoin("card_number", "subscriber_number", false),
>                            JoinBaseDN.createUseCustomBaseDN("ospobject=bundle,dc=alcatel,dc=com "), //the ‘bundle’ object DN.
>                      SearchScope.SUB,
>                            DereferencePolicy.NEVER,
>                            null,
>                            null,
>                      args_bundle,
> 
>                            true, nestedJoinval1)));
> 
> 
> 
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> 
> 
> 
> 
> The intention of the nested join is to join the subscriber and subscription objects.
> 
> But it seems that the nested join works only on the DN specified in its corresponding parent join.
> 
> 
> 
> I can’t find a way of specifying the nested join to work on the Join results of the parent join.
> 
> 
> 
> Is my understanding correct?
> 
> Do I have a way out?
> 
> 
> 
> 
> 
> 
> 
> With Best Regards,
> 
> Himanshu
> 
> 
> 
> -----Original Message-----
> 
> From: nei...@un... [mailto:nei...@un...]
> 
> Sent: Monday, September 28, 2015 7:43 PM
> 
> To: lda...@li...; SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)
> 
> Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?
> 
> 
> 
> 
> 
> Neil
> 
> 
> 
> 
> 
> -----Original Message-----
> 
> From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>
> 
> To: "lda...@li..." <lda...@li...>
> 
> Sent: Mon, 28 Sep 2015 9:05 AM
> 
> Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??
> 
> 
> 
> Hello LDAP SDK teams,
> 
> 
> 
> I am trying to implement a multi-join using the SDK.
> 
> My problem is that I have a "master" entry with 4 different attributes.
> 
> All 4 of them refer to the PK attribute of 4 other tables.
> 
> These other tables are not directly related to each other.
> 
> 
> 
> I have to implement a join on all 5 tables in a single search request.
> 
> 
> 
> The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.
> 
> 
> 
> Any ideas??
> 
> 
> 
> 
> 
> -    Himanshu
> 
> 
> 
> 

Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??

[SINGH, H. K. (H. KUMAR) <him...@al...>]

Hello Neil,



Thank you for your response and pardon me for the non-technical jargon I used. I will be as precise as possible in this text.



We have to replace an RDBMS database(specifically Oracle) with LDAP; hence the non-LDAP terms. Please excuse me for that too.

The risks, limitations and advantages are well understood; the decision has been made and design is in progress.



THE JOIN PROBLEM GENERALIZED WITH AN EXAMPLE:



- We have 4 objects, each made up of a few attributes and represented by a unique DN.



Dn: ospobject=subscriber,dc=alcatel,dc=com


Card_number


Name


Credit




Dn: ospobject=bundle,dc=alcatel,dc=com


Bundle_name


Bundle_credit


Expiry


Subscriber_number




Dn: ospobject=subscription,dc=alcatel,dc=com


Subscription_name


Expiry


Subscriber_number




Dn: ospobject=profile,dc=alcatel,dc=com


Profile_name


Profile_validity


Subscriber_number




**there are a huge number of entries in these objects. It is not possible to combine all these tables in a single table.



- Our objective is to fetch all of a subscriber’s information, including all his bundles, subscriptions and profile in a single search.

      Our JOIN conditions are:

1.  Subscriber.card_number = bundle.Subscriber_number

2.  Subscriber.card_number = subscription.Subscriber_number

3.  Subscriber.card_number = profile.Subscriber_number







What we have tried:

We came across the documentation of the commercial version of the LDAP SDK. We are trying to see if the JoinRequestControl can solve our problem.

Below is an abstract of what we have tried so far:



------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
//The attributes to be fetched
String args_subscriber[]  ={"name","credit",”card_number”};                //attributes to be fetched from the subscriber object
String args_bundle[]      ={"Bundle_name","Bundle_credit"};                //attributes to be fetched from the bundle object

String args_subscription[]={"Subscription_name","Subscription_credit"};    //attributes to be fetched from the subscription object

String args_profile[]     ={"Profile_name”};                               //attributes to be fetched from the profile object





//Define the SearchRequest on the ‘Subscriber’ object

SearchRequest searchRequest = new SearchRequest(“ospobject=subscriber,dc=alcatel,dc=com”, SearchScope.SUB, Filter.create("card_number=*"),args_subscriber); //the ‘subscriber’ DN.

.

.

.



//define the nested JoinRequestValue for the join between ‘subscriber’ and ‘profile’ objects
JoinRequestValue nestedJoinval2 = new JoinRequestValue(
                           JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),

                           JoinBaseDN.createUseCustomBaseDN("ospobject=profile,dc=alcatel,dc=com"), //the ‘profile’ object DN.
                           SearchScope.SUB,
                           DereferencePolicy.NEVER,
                           null,
                           null,
                           args_subscription,

                           true, null);

.

.

.

//define the nested JoinRequestValue for the join between ‘subscriber’ and ‘subscription’ objects

//Also add the nested JoinRequestValue defined above, to this JoinRequestValue
JoinRequestValue nestedJoinval1 = new JoinRequestValue(
                           JoinRule.createEqualityJoin("card_number”, ”subscriber_number", false),

                            JoinBaseDN.createUseCustomBaseDN("ospobject=subscription,dc=alcatel,dc=com"), //the ‘subscription’ object DN.
                           SearchScope.SUB,
                           DereferencePolicy.NEVER,
                           null,
                           null,
                           args_subscription,

                           true, nestedJoinval2);

.

.

.

//define the nested JoinRequestValue for the join between ‘subscriber’ and ‘bundle’ objects

//Also add the JoinRequestControl to the SearchRequest
searchRequest.addControl(new JoinRequestControl(new JoinRequestValue(
                           JoinRule.createEqualityJoin("card_number", "subscriber_number", false),
                           JoinBaseDN.createUseCustomBaseDN("ospobject=bundle,dc=alcatel,dc=com "), //the ‘bundle’ object DN.
                     SearchScope.SUB,
                           DereferencePolicy.NEVER,
                           null,
                           null,
                     args_bundle,

                           true, nestedJoinval1)));



------------------------------------------------------------------------------------------------------------------------------------------------------------------------------





The intention of the nested join is to join the subscriber and subscription objects.

But it seems that the nested join works only on the DN specified in its corresponding parent join.



I can’t find a way of specifying the nested join to work on the Join results of the parent join.



Is my understanding correct?

Do I have a way out?







With Best Regards,

Himanshu



-----Original Message-----

From: nei...@un... [mailto:nei...@un...]

Sent: Monday, September 28, 2015 7:43 PM

To: lda...@li...; SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)

Subject: Re: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??



It's not really clear what you're asking.  Could you provide a specific example that illustrates what you're trying to do?  And could you please use LDAP terminology, since LDAP doesn't have primary keys or tables.  Do you mean DNs and entries?





Neil





-----Original Message-----

From: "SINGH, HIMANSHU KUMAR (HIMANSHU KUMAR)" <him...@al...>

To: "lda...@li..." <lda...@li...>

Sent: Mon, 28 Sep 2015 9:05 AM

Subject: [ldap-sdk-discuss] LDAP SDK - multiple joins not supported??



Hello LDAP SDK teams,



I am trying to implement a multi-join using the SDK.

My problem is that I have a "master" entry with 4 different attributes.

All 4 of them refer to the PK attribute of 4 other tables.

These other tables are not directly related to each other.



I have to implement a join on all 5 tables in a single search request.



The nestedJoin feature of the JoinRequestControl comes close but cannot completely solve this problem.



Any ideas??





-    Himanshu