On 11 January 2011 18:17, Stevo Slavić <[email protected]> wrote:
> It seems they were.
>
> On client side of communication I now have:
>
>
> HttpDelete httpDelete = new HttpDelete(deleteUrl);
s/httpDelete/delete/ ?
>
> try {
> HttpResponse response = client.execute(delete);
> if (response.getStatusLine().getStatusCode() !=
> HttpStatus.SC_OK) {
> throw new
> SomeCustomException(response.getStatusLine().getStatusCode(),
> response.getStatusLine().getReasonPhrase());
> }
> } catch (IOException ioe) {
> throw new SomeCustomException(ioe);
> } finally {
> if (delete != null) {
delete cannot be null here, surely?
> delete.abort();
> }
> }
>
>
> Without finally and abort call in it (also with abort just on
> IOException in catch block), connections would not get returned to the
> pool in regular non-exceptional return. HttpDelete refrence is lost -
> not accessible outside of this block/method. This puts responsibility
> to the developer to clean up low level resources which weren't
> directly created or accessed - I guess it has to be like that.
Surely this is similar to closing a file?
But I agree the documentation could do with an example showcasing the
use of HttpEntity#consumeContent().
I'll add that shortly.
> Regards,
> Stevo.
>
>
> On Tue, Jan 11, 2011 at 2:23 PM, Oleg Kalnichevski <[email protected]> wrote:
>> On Tue, 2011-01-11 at 06:11 +0100, Stevo Slavić wrote:
>>> Hello httpclient-users,
>>>
>>> Beginner httpclient user here and this is more note to self and
>>> httpclient users alike. Been hit by http connection pool getting
>>> exhausted, randomly, on production... For few days I've been BMHATW,
>>> suspected even that it's a bug in httpclient 4.0.x, switched to latest
>>> 4.1-beta2-SNAPSHOT which btw works ok for me. With extra logging on
>>> client and server side of communication I've found out that delete
>>> requests didn't return connection back to the pool. After RTFM on
>>> releasing low level resources (see [1]), I've added try-finally around
>>> client.execute(httpDelete) and aborting of httpDelete in finally, and
>>> ta-da, connections would get returned to the pool.
>>>
>>> Regards,
>>> Stevo.
>>>
>>
>> Hi Stevo
>>
>> Did responses to those DELETE methods enclose a response entity? If so,
>> the entity content must be consumed in order for the underlying
>> connection to be released back to the pool.
>>
>> Oleg
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
