couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <>
Subject Re: SASL overhead (was Re: CouchDB and Hadoop_)
Date Mon, 19 Apr 2010 20:24:48 GMT
Nice! Definitely the full state should be kept if debug logging is on, but I
like this approach. I had thought of truncating the state in terminate but
hadn't put it together to check the log level and was worried about losing
debugging info.

At least this portion of the patch might be a great candidate for someone
who wants to get their hands dirty with patches.

couch_rep_* processes are a great place to start, clearing document queues
in the #state record and clearing the process message queue (is there a way
to do this in erlang that's better than a tight receive loop)?

On Apr 19, 2010 4:18 PM, "Adam Kocoloski" <> wrote:

CouchDB definitely needs a bit of spring cleaning in the logging department.
 If you haven't noticed, most error messages are written *twice* in the
logs, once in a very nice format by SASL and once in a crude format by
couch_log.  I believe this is because the couch_log event handler is
installed in the same event manager as the SASL error_logger, and because
the second handle_event clause in couch_log matches SASL-style error
reports. So even if you turned off the SASL error_logger I think you'd still
get these messages in the log.  I've been meaning to fix that ...

I'd prefer to keep the SASL-style logs, although I understand that we need
to trim them down.  That can be accomplished on a process-by-process basis
by identifying the processes with large internal states and truncating those
states in a terminate() function just before exiting (perhaps keeping the
full state if ?LOG_DEBUG is on).  Cheers,


On Apr 19, 2010, at 4:03 PM, Randall Leeds wrote:

> I've found that replication crashes pin the cp...

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