On 11 January 2011 21:21, Stevo Slavić <[email protected]> wrote: > @sebb > > 1) it's "delete" - tried to copy multiple fragments and assemble brief > readable one for the mail, made error, but I hope we understood each > other.
I was just checking. > 2) delete can be null, HttpClient.execute(HttpUriRequest request) > doesn't state request is final, so it can point to anything after > being passed to execute No, Java does not work like that. Variables are passed by value; a called method can only change the referenced object, not the value of the variable. Declaring a parameter as final just means that the parameter value cannot be changed within the method. The referenced object can still be updated if it is mutable. > 3) please don't waste time documenting to be deprecated api > As it happens, the documentation has already been updated. > @Oleg > > 4) So it's better / more recommended to consumeContent of response > entity than to abort request? Is connection considered reusable when > contentConsumed compared to abort where it gets discarded and new > connection needs to be instantiated? > > 5) I see in 4.1(-beta2-SNAPSHOT) HttpClient.consumeContent is > deprecated in favor of EntityUtils.consume - there it just gets > content stream reference and closes it so its performance is let say > constant - not affected by content size. I think I read, before 4.1, > abort was more favorable than consumeContent in cases of large > response content streams. > > 6) What if client.execute throws exception and it's not handled (so > neither response content is consumed nor request aborted), will > connection be returned to the pool, discarded as invalid, or trapped > eternally exhausting the pool? > > > > Regards, > Stevo > > On Tue, Jan 11, 2011 at 9:19 PM, Oleg Kalnichevski <[email protected]> wrote: >> On Tue, 2011-01-11 at 19:17 +0100, Stevo Slavić wrote: >>> It seems they were. >>> >>> On client side of communication I now have: >>> >>> >>> HttpDelete httpDelete = new HttpDelete(deleteUrl); >>> >>> 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.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. >>> >> >> What is wrong with just this? >> >> HttpDelete httpDelete = new HttpDelete(deleteUrl); >> HttpResponse response = client.execute(httpDelete); >> HttpEntity entity = response.getEntity(); >> if (entity != null) { >> entity.consumeContent(); >> } >> if (response.getStatusLine().getStatusCode() != HttpStatus.SC_OK) { >> throw new SomeCustomException(); >> } >> >> 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]
