couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Cottlehuber (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1520) Replicator does not close Socket in pull from HTTPS source
Date Sat, 26 Jan 2013 12:39:18 GMT


Dave Cottlehuber commented on COUCHDB-1520:

Bob, what OTP version did you test this with? There are a number of R15B* fixes for various
SSL fixes that superficially could be related.
Simon, if you can reliably duplicate this you might want to try bumping erlang to R15B03-1
and seeing if this still happens. You should recompile CouchDB after erlang as well, to be
on the safe side. Also that ubuntu is ooooold :-)
> 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