Sander Striker wrote:
>>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).
ack, good point, my bad.
-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 16:12:21 2002