incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jyrki Pulliainen <>
Subject Re: Strange bug on long polling changes feed, using OS X
Date Mon, 28 Mar 2011 13:32:14 GMT
On 28 March 2011 15: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].
> Cheers,
> Jyrki
> [1]
> [2]

I also created a ticket for this:

- Jyrki

View raw message