2009/9/9 Christopher Lenz <cml...@gmx.de>
> On 09.09.2009, at 12:19, Matt Goodall wrote:
> > I'll switch over to using it locally to test it out a bit. However,
> > I just played with it in a Python shell and got a BadStatusLine
> > exception after a couple of requests. I'll take a look later (got
> > some work to do first) and report back.
> I think that *may* be due to unread content on the socket from a
> previous response.
No, looks like an inactivity problem.
Mochiweb (the CouchDB web server component, for those that don't know) has a
default idle timeout of 30s after which it closes the connection. The
httplib branch does not appear to be handling closed connections well yet.
The standard httplib module raises a BadStatusError to indicate a (probably)
closed connection.
I guess it's fair to assume that if a valid status line is not sent back
then the server either didn't receive the request or died before it had the
chance to do anything with it. So, catching a BadStatusError, recycling the
connection and trying again is probably reasonable and, unlike httplib2, the
only time it should retry IMHO.
I don't know of any other way to detect a closed socket. IIRC, a closed
socket just looks readable after a select.select() call and you have to read
at least 1 byte to find out if there's really any data or if it's been
closed. Not very helpful and, besides, messing around with select is
probably going to lead into cross-platform problems.
- Matt
> One note on downloading attachments, as that's not documented on the
> branch yet: any non-JSON and non-empty response entity body is
> returned as a file-like object, which is either a simple StringIO
> wrapper (for small responses) or a couchdb.http.ResponseBody instance
> (a thin layer over the underlying socket).
> So whenever you get non-JSON data, which is the case for attachments
> [1], you need to either fully consume the response via .read
> ([amount]), or call its .close() method. Both result in the connection
> returning into a reusable state.
> Perhaps we can detect connections left in unusable state, and just
> close/reconnect in that case. Although, now that I think about it, if
> you don't consume/close a ResponseBody, the associated connection is
> not returned to the connection pool, either. Hm.
> Cheers,
> --
> Christopher Lenz
> cmlenz at gmx.de
> http://www.cmlenz.net/
