directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lécharny <elecha...@gmail.com>
Subject Re: LdapConnectionPool.getConnection doing extraneous search?
Date Sun, 21 Mar 2021 03:40:22 GMT
Hi Shawn,

I guess that the very first time we create the connection, when asking 
for one from a pool, we test it beforehandd, and this is done with the 
less costly operation: a dummy search.

This is due to commons-pool logic where you can ask the pool to validate 
the connection one way or the other. We are probably using 
LookupLdapConnectionValidator for that purpose:

     public boolean validate( LdapConnection connection )
     {
         try
         {
             return connection.isConnected()
                 && connection.isAuthenticated()
                 && ( connection.lookup( Dn.ROOT_DSE,  <<---- The dummy 
lookup
SchemaConstants.NO_ATTRIBUTE ) != null );
         }
         catch ( LdapException e )
         {
             return false;
         }
     }

whih get called from the public abstract class 
AbstractPoolableLdapConnectionFactory implements 
PooledObjectFactory<LdapConnection>
   class

with this method :



     /**
      * {@inheritDoc}
      *
      * Validating a connection is done by checking the connection status.
      */
     @Override
     public boolean validateObject( PooledObject<LdapConnection> 
connection )
     {
         if ( LOG.isDebugEnabled() )
         {
             LOG.debug( I18n.msg( I18n.MSG_04152_VALIDATING, connection ) );
         }

         return validator.validate( connection.getObject() );
     }

On 20/03/2021 22:57, Shawn McKinney wrote:
> Hello,
> 
> I’m using LDAP API v1.0.3 inside fortress.
> 
> My question is when retrieving connections from the pool using this:
> 
> ```
> public LdapConnection getConnection()
> 
> Gives a LdapConnection fetched from the pool.
> 
> Returns:
>      an LdapConnection object from pool
> ```
> 
> I noticed in the OpenLDAP logs (filter and stats enabled) an extra search comes through
during this invocation:
> 
> Begin slapd log trace:
> 
> ```
> [exec] 60566cd5 begin get_filter
> [exec] 60566cd5 PRESENT
> [exec] 60566cd5 end get_filter 0
> [exec] 60566cd5 conn=1010 op=5 SRCH base="" scope=0 deref=3 filter="(objectClass=*)"
> [exec] 60566cd5 conn=1010 op=5 SRCH attr=1.1
> [exec] 60566cd5 => test_filter
> [exec] 60566cd5     PRESENT
> [exec] 60566cd5 <= test_filter 6
> [exec] 60566cd5 conn=1010 op=5 SEARCH RESULT tag=101 err=0 duration=0.236ms nentries=1
text=
> ```
> 
> It’s performing a null base search with objectClass=* asking for attr ‘1.1'.
> 
> What’s going on here?  I expect to see a bind on that connection (the first time) but
not a search.
> 
> 
> Thanks,
> 
> —
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@directory.apache.org
> For additional commands, e-mail: api-help@directory.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@directory.apache.org
For additional commands, e-mail: api-help@directory.apache.org


Mime
View raw message