couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Goodall <>
Subject Re: Strange bug on long polling changes feed, using OS X
Date Mon, 28 Mar 2011 13:36:51 GMT
On 28 March 2011 13:32, Jyrki Pulliainen <> wrote:

> Hi,
> I've run into a strange bug with longpoll changes feed, using OS X. I
> can not reproduce this bug on Ubuntu Linux running the same version of
> CouchDB. This has been verified on two different OS X computers, both
> running Snow Leopard in both, 32 bit mode and 64 bit. The other one
> has the Couchbase version of CouchDB installed, the other one has one
> installed via homebrew.
> Problem is following: I have my own CouchDB driver for Tornado
> Asynchronous web framework called Trombi[1]. It's basically just a
> wrapper around HTTP calls to CouchDB, making them play nicely with the
> asynchronous nature of Tornado (unlike other Python CouchDB
> libraries). I've made a test[2] that opens up longpolling changes feed
> and writes a document in database and then waits to receive the same
> document via changes feed listener. What happens is that the changes
> feed listener never gets the reply or if it gets one, it is empty (ie.
> rows: []).
> First guess was the the use of pycurl (and thus libcurl) to be the
> problem, but after switching to pure Python SimpleHTTPClient offered
> by Tornado the problem persisted. Next I blamed it on Tornado
> framework, but further inspection using tcpdump and tcpflow revealed
> that the CouchDB actually produces an erroneous reply, an empty
> changes feed result (even though there should be at least one change).
> Has anyone bumped in to a similiar problem? I can't reproduce this on
> command line with pycurl, only with my tests. To simply reproduce this
> yourself, just clone Trombi[1], check out branch
> wip/simple-httpclient-compatibility, install tornado, nosetests and
> pycurl via pip/easy_install and make sure you have couchdb binary in
> PATH. After this, just run nosetests -v and the tests should stall on
> the test mentioned before[2].

I hit an issue on Linux so it's probably unrelated, but this sounds similar
to a problem I recently came across with the _changes feed when using a
filter and limit=1.

It's been fixed in the 1.0.x branch but I don't think it's in an official
release yet. See,

- Matt

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message