couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jyrki Pulliainen (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1105) Longpoll changes does not always work on OS X
Date Thu, 07 Apr 2011 16:33:05 GMT


Jyrki Pulliainen commented on COUCHDB-1105:

The reason was incorrectly passed Content-Length for GET request, which made CouchDB stall.
Don't know if that should be a different ticket, but at least this was fixed now.

> Longpoll changes does not always work on OS X
> ---------------------------------------------
>                 Key: COUCHDB-1105
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core, HTTP Interface
>    Affects Versions: 1.0.2
>         Environment: OS X Snow Leopard (both 32- and 64-bit): 10.7.0 Darwin Kernel Version
10.7.0: Sat Jan 29 15:16:10 PST 2011; root:xnu-1504.9.37~1/RELEASE_X86_64 x86_64
>            Reporter: Jyrki Pulliainen
>              Labels: mac
>             Fix For: 1.0.3
> 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: []).
> Problem is not my library, Tornado or the underlying HTTP client (pycurl or pure-python
implementation provided by Tornado). I can verify with tcpdump/tcpflow that CouchDB responds
with empty changes feed result after the timeout. Tests pass on my Ubuntu computer.
> Steps to reproduce:
> 1) Clone Trombi[1]
> 2) Install tornado, pycurl and nose from PyPI using easy_install/pip
> 3) Run tests, nosetests -v. Should stall on the test mentioned [2]
> I've also posted about this on mailing list[3], but figured out it might be a better
thing to create a ticket
> [1]
> [2]
> [3]

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message