directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: Creating new connections in integration tests
Date Sat, 05 Feb 2011 11:51:02 GMT
On Sat, Feb 5, 2011 at 8:35 AM, Emmanuel Lecharny wrote:
> On 2/4/11 10:58 PM, Stefan Seelmann wrote:
>>
>> Hi guys,
>>
>> one of our Hudson builds currently fails [1], the cause is an
>> IOException (Too many open files). The reason this happens is that in
>> our integration test (server-integ and ldap-api-test) we open real
>> network connections. In many cases a new connection is opened in each
>> test method. I also found a case where we open new connections within
>> a loop.
>
> I added some performance tests for each operation, but those tests are
> @Ignored.
>
> What is the tests containing a loop ?

SimpleBindRequestTest.testSimpleBindAnonymous() in ldap-api-test.

>> Most times the connections is closed after usage. However, as you
>> certainly know, there is still a problem with allocating many new
>> connections: sockets remain in TIME_WAIT state for some time after
>> bein closed, see [2]. On the Hudson servers we can of course increase
>> the ulimit -n and reduce the TIME_WAIT value. But I think that won't
>> scale when connections are opened in a loop.
>
> Sure. We can also ask to have  short lived socket, like 5 secs. Usually, a
> socket remain in TIME_WAIT state for 30 secs on a standard linux box.
>>
>> I'd like to discuss possible options to improve the situation:
>>
>> - Fist I think in general we should avoid to create new connections
>> within a loop in integration tests. We have other techniques to run
>> such test [3]. In general such test patterns are stress or performance
>> tests, but not integration tests.
>
> +1
>>
>> - Second we should avoid to create a new connection for each test
>> method. One option to achieve this is to use a single connection per
>> test class without opening/closing them @Before/@After each test.
>> Maybe the better option is to use a connection pool. Of course when
>> testing connect/disconnect/bind/unbind it may be required to use a
>> fresh connection objects.
>
> If we use our client API, we have to add a pool into the API. In the tests
> where we use JNDI, we can use a pool, that's for sure.

I just saw that we already have a LdapConnectionPool class in the API,
I'll try to use that.

Kind Regards,
Stefan

Mime
View raw message