couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jan Lehnardt (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1520) Replicator does not close Socket in pull from HTTPS source
Date Wed, 14 Nov 2012 21:24:12 GMT


Jan Lehnardt commented on COUCHDB-1520:

Is there a test script you could provide that reproduces this for you?
> Replicator does not close Socket in pull from HTTPS source
> ----------------------------------------------------------
>                 Key: COUCHDB-1520
>                 URL:
>             Project: CouchDB
>          Issue Type: Bug
>          Components: Replication
>    Affects Versions: 1.2
>         Environment: Ubuntu 8.04, Erlang 14.b.4 64bit
>            Reporter: Simon Eisenmann
>            Assignee: Robert Newson
>            Priority: Critical
>              Labels: close, https, leak, replication, socket, ssl
>             Fix For: 1.3
> When replicating using pull replication from an HTTPS-CouchDB source, the client socket
does not go away, but stays in CLOSE_WAIT forever, This will crash the whole CouchDB server,
as it will run out of file descriptors.
> This did not happen with CouchDB 1.1.
> I experimented with changing the socket options for the replicator client, though no
luck. The only change i saw  was then running with keepalive (which was the default), also
the server side (pull peer) leaks a connection. Now i am running with socket_options = [{keepalive,
false}, {send_timeout, 10000}, {send_timeout_close, true}]
>  which does not change a thing other than on the client side is leaking connections.
> To test this, you need the PID of the couchdb's beam process (ps aux |grep beam)
> Then you list all the open files of this PID with "lsof -p $PID"
> First you will see the pull connections beeing in ESTABLISHED state for a wile (even
when the replication itself is long finished), Then at some point it switches to CLOSE_WAIT.
The client side socket needs to be closed by the replicator to go away and release the resources
(eg. file pointer).

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message