On Tue, 2011-01-11 at 22:21 +0100, Stevo Slavić wrote: > @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? >
Connection cannot be re-used if the request executed over that connection is aborted. If the entity enclosed with the response is consumed in an orderly manner the connection remains in a consistent state and therefore can be potentially re-used. > 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. Not really. The #close() method always attempts to read the remaining content and therefore its performance is directly proportional to the size of the remaining content. In your case the size of the response content to a DELETE method is likely to be very small. > I think I read, before 4.1, > abort was more favorable than consumeContent in cases of large > response content streams. > Both methods have their pros and cons and should be used when appropriate. > 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? > HttpClient automatically discards the underlying connection if request execution terminates with an exception. One has to worry about resource deallocation _only_ if a valid response is returned which encloses an entity. Hope this helps Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
