> On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>
> LDAP connections are quite stable. Again, this check is there to respect the
> commons-pool API contract. If the connection is dead, then doing this check
> will let the pool fetching another connection, which is good. OTOH, if you
> don't want to check connections while fetching one, then you are on your own
> (ie, deal with the consequences of a bad connection).
Again, I must disagree. Connections aren’t stable, subjected to env conditions
and we can never assume a connection is good. Something in the API chain must
do the job of testing and reconnect, every time it’s pulled from the pool.
Now, having said that, that’s exactly what I’m observing currently, with the
test on borrow flag turned off.
Let me explain the scenario:
1. Start server
2. Start client
This initializes a connection pool which creates and stores exactly 1
connection (min 1, max1 )
3. Set breakpoint in client on pool.getConnection method
4. Restart the server.
5. Client performs ldap op which triggers the breakpoint on getConnection
6. Server at this point still hasn’t any connections with the client. The
client ‘thinks’ it has connections in the pool, but these were broken on step 4.
7. Step over the getConnection which then triggers the commons pool to execute:
```
GenericObjectPool._factory.activateObject(latch.getPair().value)
```
8. A connection is made with the server, along with bind
```
6058e163 conn=1000 fd=14 ACCEPT from IP=127.0.0.1:35246 (IP=127.0.0.1:389)
[exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com"
method=128
[exec] 6058e163 conn=1000 op=0 BIND dn="cn=manager,dc=example,dc=com"
mech=SIMPLE ssf=0
[exec] 6058e163 conn=1000 op=0 RESULT tag=97 err=0 duration=1.667ms
```
9. Client continues with its ldap op successfully and is never the wiser that
the connections were all forcibly closed on server restart.
This is EXACTLY what I want to see all of which is done without the test on
borrow eliminating the extraneous search on every connection retrieval.
—
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org
