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
