Hmm, that sounds like a bug to me then. Not familiar with the specifics, but a "correct" HTTP client implementation should definitely not block on the connection closing to complete a read. Maybe it is being too greedy about filling up a buffer or something?
I haven't been in this code for quite some time, so hard to comment definitively. Just my philosophical opinion on this one -- moving to always close the connection seems like a workable but suboptimal fix. -----Original Message----- From: Kerr, Rowan [mailto:[email protected]] Sent: Tuesday, April 26, 2011 3:56 PM To: [email protected] Subject: Re: HttpClient Connection close bugs Observed behavior was that reading an object from response would not return the object until connection closed. On 11-04-26 2:32 PM, "Mark Slee" <[email protected]> wrote: >This should definitely be a configurable option, but I think the default >should definitely be *not* to send the close header. As far as I >remember, the Thrift HTTP clients were intentionally written to support >keep-alive, which is definitely the best way to use them if making >repeated requests. > >Philosophically, I think we should err on making it easier to get things >right in the high-volume, high-performance case. IMO, keep-alive should >be something that "just works" if you do the naïve thing (construct a >THttpClient and issue multiple subsequent RPC calls on it with no extra >lines of code in between). > >If you're closing your connections after every unique request, your perf >requirements are probably less stringent than someone who's pushing many >requests over shared connections. > >Cheers, >mcslee > > >-----Original Message----- >From: Usman Ismail [mailto:[email protected]] >Sent: Tuesday, April 26, 2011 11:22 AM >To: [email protected] >Subject: Re: HttpClient Connection close bugs > >As far as I can tell for c++ and objective c we are not actually using >persistent http, i.e. we do not reuse open connections. Hence not >setting the close header just means it takes longer to close the >connection. In the long run I agree we should explore use of >persistent http connections as well as user specified headers. > >--usman > >On Tue, Apr 26, 2011 at 2:12 PM, Seth Hitchings <[email protected]> wrote: >> Using keep-alive should improve performance, not degrade it. Adding >> Connection: close would significantly degrade performance, especially >>for >> HTTPS connections. >> >> In general, it would be great if all of the HTTP client transports >>exposed >> the ability to customize headers, so that an app could override >>defaults or >> add custom headers without modifying the client itself. >> >> Seth >> >> On Tue, Apr 26, 2011 at 10:43 AM, Usman Ismail <[email protected]> >>wrote: >> >>> Hi, >>> >>> I had a look at the Objective C and C++ http client code and noticed >>> that it does not supply the Connection: close header. This means that >>> webservers keep the connection alive assuming its a persistent >>> connection. This slows down client side request processing >>> significantly and also wastes server resources. I created issues 1153 >>> and 1154 for c++ and objective c respectively it would be great to >>> have then in the next release. >>> >>> I also noticed a similar issue in java although I am not sure whether >>> the the change is needed in java or whether underlying layers take >>> care of it. >>> >>> --regards >>> Usman Ismail >>> >> >
