couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nick Wood <>
Subject Re: crash reports
Date Fri, 29 Jan 2016 17:23:14 GMT
I updated both servers to use this container image - which is what I
believe the CouchDB team is trying to base it's official docker image off
of. Still getting lots of crashes and replication isn't starting much of
the time. For example, right now I have over 100 documents in the
_replicator database. 1 of them is "triggered", about 15 are in an error
state with the reason being "timeout", and the rest haven't even been
started (_replication_state isn't set).

When I cycle through all ~1100 of our databases and do a non-continuous
replication, I don't receive a single error or crash. I continuously queue
20 of them into the _replicator database and I can see it processing about
2 per second. (on a side note, any idea why it only does 2-3 per second
when I can see plenty of available disk, ram and cpu? Seems like there's an
internal hard-code delay maybe?)

The issue happens when I try to initiate continuous replications.

Might I still have a broken version of erlang? It looks like the version I
ended up with using that docker image is 17.3.


On Thu, Jan 28, 2016 at 4:27 PM, Alexander Shorin <> wrote:

> On Fri, Jan 29, 2016 at 2:12 AM, Nick Wood <> wrote:
> > This is from over 11 months ago. It looks like 18:2 is available. Do you
> > think it's worth upgrading to see if it fixes the issue? Or is it the
> later
> > 18.x releases that may have caused the crashes you mentioned?
> No, upgrade to 18 won't work, actually, for you. If you upgrade
> Erlang, you need to rebuild CouchDB to avoid any kind of problems and
> 18 support will require tiny, but sources patch.
> However, if you didn't touch anything for 11 month, then no idea for now.
> Your problem is that replicator httpc (http client) pool get instantly
> killed on the initialization. Why that happens? Good question.
> --
> ,,,^..^,,,

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message