[jira] [Commented] (COUCHDB-2912) Hanging _changes in longpoll feed with _doc_ids filter when other document changes

["Myroslav Opyr (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COUCHDB-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15047412#comment-15047412 ] 

Myroslav Opyr commented on COUCHDB-2912:
----------------------------------------

I'd discussed this issue with Kxepal and damjan on irc://irc.freenode.net/couchdb today. Some of the side notes are:

# Client connections come from PouchDB, but REQUIRE _doc_ids filter. Without that filter all connections just react to change on database and return changed document.
# The issue to become significant requires client to timeout soon after expected timeout, and restart the longpoll request, for sockets to start building up. It is usually not noticeable when there are several "hanging" sockets, but becomes obvious when there are tenth and hundreds of reconnects upon client-side timeouts.
# On that particular server it is enough to reach 1500 sockets in CLOSE_WAIT state to kill CPU (100% load), see [^cpu.png].

> Hanging _changes in longpoll feed with _doc_ids filter when other document changes
> ----------------------------------------------------------------------------------
>
>                 Key: COUCHDB-2912
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-2912
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Database Core
>    Affects Versions: 1.6.1
>            Reporter: Myroslav Opyr
>         Attachments: couchdb_clients_requesting_changes.png, couchdb_httpd_request_methods.png, couchdb_httpd_requests.png, couchdb_request_times.png, cpu.png
>
>
> Primary issue is:
> # spawn many (70+) longpoll changes requests like:
> /_changes?timeout=26892&style=main_only&include_docs=true&feed=longpoll&filter=_doc_ids&doc_ids=%5B%2253b64bc66e3e4cff9d195c53da691a9b%22%5D&since=95354&limit=25&_nonce=1449572474544
> # change document with id OTHER then 53b64bc66e3e4cff9d195c53da691a9b.
> # all spawned connection never respond (hang forever)
> Secondary is:
> # Clients time-out and close HTTP connection on all spawned longpoll requests
> # CouchDB leaves socket in CLOSE_WAIT state for quite some time consuming available to CouchDB process file descriptors, but eventually (sometimes after quite long time) closes them.
> Tretiary is:
> # Having many sockets in CLOSE_WAIT state (like described above), CouchDB CPU consumption significantly raises overloading the server.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)