#35 Request/response object leak

open
nobody
None
5
2008-06-13
2008-06-13
No

One of the Hudson users reported a problem <https://hudson.dev.java.net/issues/show_bug.cgi?id=1838>, which seems like the request/response object leak.

That is, the server is clearly not handling 1000 concurrent requests, yet the ObjectPool class denies the allocation of request, citing the maximum is reached.

The only valid explanation seems to me that the object is leaking.

Looking at ObjectPool, I think the implementation approach is rather prone to memory leak. First, since the request handling thread itself is bound by the limit, this places natural upward bound in the # of request/response object that are concurrently in use, so the value of placing a limit is questionable.

Also, if you do feel it's necessary to put a cap on the pool, you should just make sure that 'unusedRequestPool' doesn't grow beyond certain size. There's no point in keeping track of 'usedRequestPool'.

Discussion

  • Johan Eriksson
    Johan Eriksson
    2008-12-05

    Hi.

    I couldn't find an existing solution for this bug..

    I applied the following patch to revision 1.13 of Ajp13Listener.java. Change adds deallocation of req/resp. resources when WinstoneException is thrown in Ajp13IncomingPacket constructor.

    167a168,172
    > if (req != null)
    > this.objectPool.releaseRequestToPool(req);
    > if (rsp != null)
    > this.objectPool.releaseResponseToPool(rsp);
    >
    171d175
    < deallocateRequestResponse(handler, req, rsp, null, null);
    173a178,184
    > } catch (WinstoneException err) {
    > if (req != null)
    > this.objectPool.releaseRequestToPool(req);
    > if (rsp != null)
    > this.objectPool.releaseResponseToPool(rsp);
    >
    > throw err;

    This fix solved the problem I had in my setup, running mod_jk version 1.2.25 with following configuration:
    .socket_keepalive=1
    .socket_timeout=5
    .connection_pool_timeout=600

    Best regards
    Johan Eriksson