incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Alfke <j...@couchbase.com>
Subject Re: Considering CouchDB
Date Wed, 20 Nov 2013 16:56:19 GMT

On Nov 20, 2013, at 8:01 AM, Robert Newson <rnewson@apache.org> wrote:

> There's no such thing in couchdb. Databases are append-only, there's a
> single writer, but concurrent PUT/POST requests are faster than serial
> anyway, and each writes to different databases are fully independent.

And read requests are never, ever blocked, even during a write, even during compaction —
that’s a pretty significant win.

> 2) Stack traces are hard to read, not impossible, but couchdb will
> send useful errors, we don't just dump stack traces (that is, the
> "crash only" thing does not extend to the API)

To be honest, I find CouchDB’s error logging pretty awful. Perhaps the most awful of any
server I’ve ever used. The stack dumps are effectively impossible to interpret unless you
know enough Erlang  to be able to look up the source code references and figure out what the
functions are doing. Nearly everything ends up as a “badmatch" exception because Erlang
relies so heavily on pattern-matching, so that message tells you nothing unless you go into
the source to find out what the pattern is and what it might have been supposed to match.

This is made worse by the fact that many input errors that CouchDB should detect explicitly
and log as a comprehensible message (parameters out of range, unexpected end of input, incorrect
MIME types, etc.) are just handled via pattern-matching, so they result in huge stack dumps
instead of a to-the-point error message. (And the client is even worse off, getting a plain
500 error rather than a more useful 4xx with a message saying what’s incorrect.)

—Jens
Mime
View raw message