CouchDBX log view can prevent CouchDB from handling requests

[natevw]

It would seem that CouchDB has a finite buffer for log messages that blocks HTTP requests when full. When CouchDBX has a large log history it will slow down AppKit's rendering, especially on resize or during a scroll bar adjustment, which can result in the underlying server hanging as well if it is receiving requests rapidly. This happens even if the log view is snapped all the way shut using the splitter thing.

If you hold down CouchDBX's scroll bar handle, a bash loop like the following eventually stops counting, with curl stuck waiting for a response from CouchDB:
while [ 1 ]; do let i=i+1; echo $i; curl localhost:5984; done

In Snow Leopard, Apple added a canDrawConcurrently method to NSView which may (NOTE: or may not) help the window resizing issue. However, the log blocking while holding the scroll bar may be due to the scroll view using a blocking event-handling loop (http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/EventOverview/HandlingMouseEvents/HandlingMouseEvents.html#//apple_ref/doc/uid/10000060i-CH6-SW4) and if that is the case wouldn't be helped by concurrent view drawing anyway.

I wonder if a more reliable way to deal with this would be to have CouchDB log to a temp file on disk, which CouchDBX would read in 'tail -f' fashion.

[I guess this really applies more to https://github.com/janl/couchdbx-app, but looks like this project is the one that's collecting tickets for the Cocoa app as well.]

[natevw]

Adding some notes for future me or whoever gets a chance to tackle this first:

The CouchDB server is started via an NSTask with pipe notifications registered on the main thread's run loop. Still paging Cocoa stuff back into the front of my mind, but based on some comments on a thread I found (http://www.cocoabuilder.com/archive/cocoa/284820-problem-with-reading-an-nspipe-nsfilehandle-to-end.html, "When you invoke -readInBackgroundAndNotify, there is a run loop source installed on the run loop associated with the current thread. That is, if you invoke -readInBackgroundAndNotify on a background thread, the run loop source is installed on the background thread's run loop.") the solution may be as simple as registering for the data notifications via a background thread that subsequently starts polling its own run loop. When a data event comes in, we can pull that data from the system pipe buffer (which is probably the "finite queue" we are seeing CouchDB act as if it has) and send it off via a performSelector to the main thread's run loop (which will retain the data until it is gotten to).