On Thu, 2011-10-06 at 02:59 -0700, David Hosier wrote: > Ok, I see what the difference is in this situation. I am not passing the > ResponseHandler to the execute() method. I am actually calling > handleResponse() on the ResponseHandler manually.
I honestly see no sense in doing so. ResponseHandler is pretty much useless without the resource management code in AbstractHttpClient. What is the reason you want to invoke #handleResponse manually? Oleg > The problem I have with the implementation is that I return error messages > on error conditions. With the way this works, you can only get very basic > information from the HttpResponseException. For example, on a 404, it looks > like the Exception only contains 404 and 'Not Found'. I am able to pluck out > the entity when invoking handleResponse() manually by simply consuming the > entity myself, but it's not possible to get the entity if the ResponseHandler > is passed to execute() and the status is not 2xx. Am I off base here or is my > analysis correct? Would you recommend that if I really need the entity on a > non-2xx response that I just keep manually consuming the entity? I'm not sure > it would make sense for your library to attempt to consume the entity in > BasicResponseHandler and try to add it as an > other fi > eld to the HttpResponseException. The AbstractHttpClient code you linked me > to would have to change if you did that. > > -- David Hosier > > On Thursday, October 6, 2011 at 2:30 AM, David Hosier wrote: > > > On Thursday, October 6, 2011 at 2:22 AM, Oleg Kalnichevski wrote: > > > On Wed, 2011-10-05 at 13:44 -0700, David Hosier wrote: > > > > Perhaps I'm wrong, but the code for BasicResponseHandler in httpclient > > > > 4.1.2 does not satisfy the javadocs as written. The javadoc states the > > > > following: > > > > > > > > "If the response code was >= 300, the response body is consumed and an > > > > HttpResponseException > > > > (http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/client/HttpResponseException.html) > > > > is thrown." > > > > > > > > However, the code does not do that: > > > > > > > > StatusLine statusLine = response.getStatusLine(); > > > > if (statusLine.getStatusCode() >= 300) { > > > > throw new HttpResponseException(statusLine.getStatusCode(), > > > > statusLine.getReasonPhrase()); > > > > } > > > > > > > > HttpEntity entity = response.getEntity(); > > > > return entity == null ? null : EntityUtils.toString(entity); > > > > > > > > The code clearly throws the Exception without reading the entity. So > > > > what happens is that if you get a non-2xx response, connections are > > > > never released as can be seen by enabling DEBUG logging for the > > > > library. Am I misreading the code or javadocs, or is this really > > > > broken? If I catch the Exception and then read the entity manually like > > > > shown above, I can see the connections being closed. > > > > > > > > -David > > > > > > Hi David > > > The resource management is taken care of by HttpClient [1]. I do not > > > think BasicResponseHandler is broken. The whole point of ResponseHandler > > > is to free the user from having to worry about resource management and > > > response entities. > > Interesting. Thanks for the link to the code. I can assure you that in my > > situation however, that the connections are not getting closed. I'll take a > > closer look at the code and compare it to this linked code to see if I'm > > using the right stuff. My assumption at this point then is that I'm just > > doing something wrong. Thanks. > > > > > > Oleg > > > > > > [1] > > > http://hc.apache.org/httpcomponents-client-ga/httpclient/xref/org/apache/http/impl/client/AbstractHttpClient.html#930 > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: [email protected] > > > > (mailto:[email protected]) > > > > For additional commands, e-mail: [email protected] > > > > (mailto:[email protected]) > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > (mailto:[email protected]) > > > For additional commands, e-mail: [email protected] > > > (mailto:[email protected]) > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > (mailto:[email protected]) > > For additional commands, e-mail: [email protected] > > (mailto:[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]
