On Fri, Nov 14, 2008 at 9:52 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> response was, essentially, "Meh".
Not true. As I recall it, my response was more like, "Hmm, all of the
editor drives that we implement don't care about this constraint.
Perhaps this constraint is not as important as we initially thought;
therefore, we should relax that constraint."
> Even when others stepped up to describe
> how a high degree of parallelism could still be maintained while honoring
> the API, no effort was invested into making ra_serf do the right thing. And
That certainly doesn't match my recollection of the conversation. The
only response that I recall that was championed was to disable
parallelization/async entirely. It should be obvious why I felt that
was a non-starter...
> 1. Rev the editor API to relax some of the ordering restrictions (and of
> course do so in a way that still makes for a sane API), and then
> tweak ra_serf to use the new editor API, or
+1. =)
> 2. Fix ra_serf to honor the existing API.
If it can indeed be done without disabling parallelism or sacrificing
speed, I'm open to suggestions.
> jerking away the client-side implementation that works in all cases. We
Frankly, you have to do some very poor tuning in order to make it slow
- essentially turn off keepalive or set a low keepalive counts -
neither of which are the default behavior - the server admin has to
*explicitly* configure it in such a poor way. Even then, serf *does*
work - serf will figure out the keepalive threshold and respect it
after it gets burned initially. (And, given the fact that some
servers are mis-tuned to begin with is why multiple connections can be
a win w/ra_serf even if there isn't a load-balancer or whatnot in
front of it.) Given the server config, serf will do the best job that
it can - but if the server admin mis-tunes their httpd instance, then
there's not a whole lot that can be done.
However, to say that it doesn't work isn't a fair claim. Is it
optimal? No. But, I can do lots of things to httpd to screw ra_neon
over too. (I had to add a lot of complexity to support servers that
had poor Keepalive values.)
(I've heard sporadic reports of Google Code Hosting acting a bit funny
- it does work for me after they made some changes, but for some, it
appears that ra_serf can trip up some DoS detection code within Google
that causes it to sever the connections. I'm sure if it became a
priority, Google would fix that.)
> who routinely writes code against Subversion's APIs, I take API promises and
> compatibility seriously.
I do too, but even still reading that one obscure comment (ordering
rule #3) in svn_delta.h (which I probably overlooked at the time), I'm
still not sure I would have understood what it meant. The breakage
certainly wasn't intentional on my part - but once it was pointed out,
I think the constraint doesn't gain us anything and that it comes with
a substantial penalty. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-14 16:35:07 CET