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-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org


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

Reply via email to