Re: Ldap pool issue...

[Emmanuel Lécharny <el...@gmail.com>]

Le 31/12/14 20:41, Lucas Theisen a écrit :
> I just attempted to reproduce using:
>
>> I have done one more test : I'm now using only 2 threads, and set the
> maxIdle to 0. What happens is that after a few connections, only one thread
> is still accessing the server
>
> But the test completed successfully.  I am running on windows with java
> 1.7.0_15...  Is it supposed to succeed and i would only notice the log
> messages you mentioned?  Or should i expect it to fail when it encounters
> one of those fail messages in the log?  What is your log config to see
> those messages?
The test will always succeed, it's just that it will wait for the
timeout of a broken connection from time to time.

>
> Also, I was thinking about improving the performance of the
> ValidatingPoolableLdapConnectionFactory by maintaining an indicator as to
> whether a bind was called while the connection was checked out and only
> rebinding on return if it was.  
Any improvement in this area is very welcome ! I just rrally created a
new class for non-validating connection because it was soo slow, without
thinking about how to speed up the existi,g pool.

Now, most of the time, a Bind will be called, and must be called, just
because otherwise, it leaves the connection in a state that might be
unsafe : typically, if a StartTLS extended operation has been called. An
alternative though would be to set a flag when one StartTLS has been
sent, and in this case, then we must unbind and re-bind.

So, yes, your approach would work and speed up the validating pool.

In fact, we were doing way too much, by doing :
- a unbind/bind when the connecion was put back in the pool (we should
unbind/bind only when a StartTLS operation has been sent, or if a Bind
has been done)
- a search for the RootDSE everytime we were pulling a connection from
the pull, instead of simply checking that the connection is still enabled

> This could be a counter that gets
> incremented with each bind that the pool could check on return or even just
> a boolean that gets set to true when bind is called an can be set to false
> when the pool rebinds to the configured user.  This could be done directly
> in the existing connection implementation or I could write a decorator to
> add the additional field.  What do you think?

Whatever works :-) The key here is to let the user decide what to do,
and be aware of the options. This is a critical part of the API, and if
we don't provide teh right implementation, people will start blogging
about it saying that "it's way slower that XXX or YYY API...".

Thanks !

Re: Ldap pool issue...

[Emmanuel Lécharny <el...@gmail.com>]

Some insights : This is not a thread issue. I'm able to reproduce the pb
with only one thread pounding the server with new connection requests
(ie, it gets a connection, and move it back to the pool as soon as the
search is done, and the pool just close the connection).

Here is what I get :

Iteration 1
Thread Thread[Thread-2,5,main] completed in 10135ms
0
1000
2000
3000
4000
------>>   Cannot get the connection... Retrying
Thread[Thread-3,5,main] failed to get a connection on iteration 4363 :
Cannot connect on the server, the connection is invalid

It's quite systematic : after 4363 connections, it get blocked.More
investigations to come.