> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> Sent: 20 September 2002 15:26
> Philip Martin wrote:
>
> >>so that it, itself, is unlikely to fail without releasing the
> >>locks that it holds. Further, the listener mentioned in (2)
> >>can detect when this (extremely rare) failure happens, and DTRT.
> >>
> >>I think this may be the easiest safe strategy (though it does
> >>require a daemon) (which might be auto-started, as mentioned
> >>before).
> >
> >
> > What worries me about this proposal is the performance impact on
> > mod_dav_svn. We already have a sophisticated server, Apache, where
> > the fork/exec stuff has been abstracted into the MPM modules. Adding
> > this new server imposes the fork/exec model again. Will this degrade
> > (Windows?) servers?
> >
> > Aside from the multi-processing issue, I'm also concerned about memory
> > usage. Everything into and out of the database now requires memory to
> > be allocated in both Apache and the new server. There is also the
> > overhead of sending the requests over the local socket.
> >
> > Now, ra_pipe will require some sort of svnd server, but that should be
> > handling ra requests.
>
> nothing says that this theoretical server has to be used for ALL
> filesystem access... (well, maybe bill wants it to be, but personally,
> i don't thing it's a 'hard and fast requirement') we could have it only
> used for mediating access to the repository for ra_local, and then build
> enough smarts into the apache module to deal with similar problems (like
> philip theorized about in another email).
Sure it needs to be ALL access. Consider mixed environments where both
ra_local and ra_dav are used... (and maybe other ra_ layers).
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 16:08:37 2002