Paul, 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 couch_query_servers:get_ddoc_process 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, Norman On Wed, Jan 26, 2011 at 5:52 PM, Paul Davis <[email protected]> wrote: > On Wed, Jan 26, 2011 at 7:03 PM, Norman Barker <[email protected]> > 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] > https://github.com/apache/couchdb/blob/trunk/src/couchdb/couch_os_daemons.erl >
