Re: LdapConnectionPool.getConnection doing extraneous search?
Would a Java Dynamic Proxy help? It would implement the LdapConnection interface. When a method is invoked it borrows a connection from the pool (without testing it), executes the method, returns the connection to the pool, and returns the result. When the method execution fails with a specific error (connection error) it invalidates the object in the pool, borrows a new one, and retries. Kind Regards, Stefan - To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org
Re: LdapConnectionPool.getConnection doing extraneous search?
> On Mar 22, 2021, at 11:05 AM, Emmanuel Lécharny 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
Re: LdapConnectionPool.getConnection doing extraneous search?
On 22/03/2021 16:45, Shawn McKinney wrote: On Mar 22, 2021, at 10:43 AM, Shawn McKinney wrote: The risk not doing such a check is very very tenuous. Sorry, but asking for a clarification here. Do you mean, not doing the check is risky? Or, is OK. 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). Usually, under heavy charged systems, it's better not to check connections, except on exceptional conditions: * if the connection works, well, you are good to go * if it fails, it's time to activate contingency plans (here, try to borrow another connection from the pool) You are very much likely to fell in the first situation. - To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org
Re: LdapConnectionPool.getConnection doing extraneous search?
> On Mar 22, 2021, at 10:43 AM, Shawn McKinney wrote: > >> >> The risk not doing such a check is very very tenuous. > Sorry, but asking for a clarification here. Do you mean, not doing the check is risky? Or, is OK. > This is what I was hoping you were going to say. I’ve tested restarting the > server after the pool was created and it seems OK. - To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org
Re: LdapConnectionPool.getConnection doing extraneous search?
> On Mar 21, 2021, at 12:59 PM, Emmanuel Lécharny wrote: > >> >> When I flip that switch, the dummy search no longer occurs when connection >> is retrieved, which is `good. >> Wonder what we lose. Recovery from connections being timed out by server or >> reset by intermediaries like routers? > > Not that much. The gain is not enormous either, just a round trip. The LDAP > server is not under heavy strain with such a request, it's an automatic > answer. This is what you would use for a Health Check. > I’m going to have to respectfully disagree here. Under heavy load situations, that round trip can be costly. Even 10ms is a waste of time because Fortress grabs a connection from the pool and performs (usually) just one operation. Having that extra round trip per operation is unacceptable, regardless of what it may be doing to/on the server. > The risk not doing such a check is very very tenuous. This is what I was hoping you were going to say. I’ve tested restarting the server after the pool was created and it seems OK. > However, we have implemented it as commons-pool requires it to be > implemented. The question would be to know if we should make it a default. Now that I understand what’s going on, I’m going to turn this off by default. It can still be enabled in the fortress config, but don’t see a need for it. One more question, is this: adminPool.setTestWhileIdle( testWhileIdle ); Not as concerned about it but wonder if it can safely be turned off as well. Thanks for chiming in Emmanuel. — Shawn - To unsubscribe, e-mail: api-unsubscr...@directory.apache.org For additional commands, e-mail: api-h...@directory.apache.org
