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 !
