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 >> >
