> And read requests are never, ever blocked, even during a write, I don't think this is true. A write requires updating views and reads have to wait for the update. You can tell it to not wait and use stale values but that impairs consistency.
On Wed, Nov 20, 2013 at 8:56 AM, Jens Alfke <j...@couchbase.com> wrote: > > On Nov 20, 2013, at 8:01 AM, Robert Newson <rnew...@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
