On Thu, Nov 29, 2012 at 4:52 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> [I'm going to try to summarize the body of responses generated from this
> original query -- a conversational reset, if you will -- so as to keep this
> line of inquiry moving toward closure.]
>
>> 3) libsvn_ra_serf stabilization. I know there have been a couple concerns
>> that Philip has raised (EAGAIN and the random failures).
>
> Philip and Ivan both seem keen on reinstating ra_neon.
>
> Justin poopooed the idea of reinstating ra_neon simply to get 100% feature
> coverage, suggesting that the way forward for the believed-to-be-small
> fraction of folks depending on Neon-specific features is to just stick with
> 1.7. (Not sure how serious he was.)
>
> Mark expanded the scope of the discussion to include Serf's affect on
> servers (growth of server logs, expanded number of server connections, etc.).
Just for the record, I believe someone else raised the log issue this
time and I merely participated in the ideas around how the log entries
might be controlled. I did raise the connection issue. I pointed out
that our testing revealed that KeepAlive and caching made it
manageable but without that it could be a problem. Stefan K.
indicated there might be Windows SSPI scenarios where this could be a
problem.
For the record, I feel like we already have made the decision on Neon
and need to move forward to get Serf ready.
One thing you did not mention (but I see has now been brought up in
the replies) is that I re-raised Ivan's suggestion about making Serf
have a way where it behaves like Neon during checkout/update. Since
you said you are working on it, I will just say how I would like to
see it work:
* When talking to pre-1.8 servers it should always behave like a Neon client.
* When talking to a 1.8+ server it should behave like a Neon client by default
* The server should support a directive that tells the client it can
open multiple connections and just fetch a skelta. I would assume the
server would advertise this in OPTIONS and the client would then
behave accordingly. We could conceivably use the existing Neon
directive for this (SVNAllowBulkUpdates), which would even work for
older servers I guess, but given that this directive would negatively
effect Neon clients (since Neon does not handle this mode as well as
Serf) perhaps it should be a new directive.
This would allow server administrators to have some control over how
their server was accessed and make the decision that is best for their
environment and workload. For administrators that are concerned about
log size or connections they can avoid that problem and the new
behavior would become an opt-in feature for administrators that want
the new features and can benefit from them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2012-11-30 18:29:56 CET