couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Barker <>
Subject Re: os_daemons and query_servers
Date Wed, 16 Mar 2011 00:53:36 GMT

thanks for the os_daemon code, it is great.

I found the timeout bug we were seeing, it is in
couch_query_servers:get_os_process and

there is a gen_server:call that uses the default of 5 seconds, if the
external process takes longer than  5 seconds to start (which in our
case it sometimes does) then we get a bunch of timeout errors, I used
gen_server:call with infinity and it works fine.

Thanks for the help,


On Wed, Jan 26, 2011 at 5:52 PM, Paul Davis <> wrote:
> On Wed, Jan 26, 2011 at 7:03 PM, Norman Barker <> wrote:
>> Paul,
>> understand the answer is no (currently), then why?
> As Randall says, the protocol between the two types of OS processes is
> quite different. Each protocol is generally a request/response type of
> protocol, except the actors are switched. In the view server code, it
> is Erlang making requests to the OS process, and for os_daemons, it is
> the OS process that makes the request. Interleaving the two would
> undoubtedly cause more headaches for both the Erlang implementation
> and anyone wanting to write an OS process that implemented one or both
> protocols.
> That said, there's not really a whole lot of code in regards to os
> daemons. I think you'd be hard pressed to find examples of where we
> could share code between the two processes without overgeneralizing
> functions to the point where they're harder to reason about. The
> entire os_daemons module [1] (which is almost entirely self contained)
> weighs in at 364 lines (total, not discounting blank lines or
> whitespace).
>> a view server can be an external process, python for example, so now
>> we have two external managers within couch, why? Why fix a bug in two
>> places (I am verifying a timeout bug with the query_servers for an
>> external process).
> I will give you five internets if you show me a timeout bug that
> exists in both the os_daemons code and view_server code.
> That said, the os_daemons code was written after the initial view
> server implementation using a couple paradigms that I've learned since
> last hacking on the view managers. There are definitely bits we could
> port back to the view server manager to simplify a lot of logic.
>> Is combining os_daemons with external query_servers worth doing, if I
>> do this and add a patch can I get this into the trunk?
> If you wrote something we would of course consider it. Although,
> perhaps I'm too close to this code but I can't really see a way to
> combine these two features into a single implementation that wouldn't
> magnify the complexity somewhere, either in CouchDB itself, or inside
> the external processes.
> On the other hand, the view server code is in desperate need of a make
> over. Adam and I have made attempts independently but neither of us
> has committed anything.
>> thanks,
>> Norman
> [1]

View raw message