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).
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 20 15:26:55 2002