couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <>
Subject Re: Proposal for changes in view server/protocol
Date Mon, 02 Aug 2010 21:53:56 GMT
On Mon, Aug 2, 2010 at 1:02 PM, Benoit Chesneau <> wrote:

> On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers <>
> wrote:
> >>
> >> Before doing any changes to view server protocol, I would prefer to
> >> start working on a better implementation of js insde CouchDB. The
> >> current implementation (ie using one os process for each call/request
> >> ) even limited in a pool of process limit what you can do for obvious
> >> reason.
> >>
> >
> > What limitations do you mean?
> - difficult to watch processes

I would argue that it's trivial to watch processes because they are only
allowed to do processing in between request/response cycles in the protocol.

> - number of fds used under big load witch could limit in the same time the
> db
> - passing message in json from and back (this imo could be at some
> time removed imo

I want to see this in the external process handler but not in the view
server. Again, I think the view server should remain in scopeing documents,
queries, and other operations to clear functional transforms.

> - can't stream in this os process without creating another

So, the process shouldn't be able to actually handle another call until the
current one returns. It should only block the response on processing.

I would like to see some alternative for languages like Java that take
forever to start a new process and can scope the multi-core on their own.

> ....
> >
> > I don't think the view server should ever *block* on anything other than
> > processing and should still be forbidden from doing IO.
> There some IO you want like process http in a show to get another
> message, some other stuff can be imagined.

No, it shouldn't. The HTTP response for a document should be
deterministically generatable for that revision of the document. If you
actually generate a different response for a doc@rev based on some external
IO call then you break all the caching.

> >
> > We do need to implement a non-blocking line protocol for external
> processes
> > and maybe some better support for a long term generic changes listener
> but
> > allowing the view server to go off and do IO is an *incredibly* bad idea.
> >
> >
> external processes have  disadvantages I said. I never speak about
> view server in this case. Actually using view server to handle shows,
> lists & such is like a big hack . It could be done in a simpler
> manner.
> We could imagine js contexts making RPC to pure erlang and erlang
> sending back the response, stuff like it.

I'm going to writeup my proposal for a better external processes protocol in
another email. It needs to get significantly better.

I don't see the value in overloading the current view server with an RPC
back to erlang. It breaks far more things than it solves.  If we want a
bigger application platform that can do all these things and doesn't want
the caching and wants to break the functional tranform model of the view
server perhaps we should design an alternative that doesn't also deal with
the views and current work load of the view server but is scoped to a design
document instead of being like the external process handler.


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