On Wed, May 2, 2012 at 6:45 PM, Greg Stein <gstein_at_gmail.com> wrote:
>
> On May 2, 2012 10:26 AM, "Johan Corveleyn" <jcorvel_at_gmail.com> wrote:
>>
>> Innocent bystander's question, before 1.8 starts to be cast in stone:
>> what's the status of ra_serf?
>
> I've been using it exclusively for years. It has been totally fine.
>
>> Will we (again) attempt to make serf the
>> default in 1.8?
>
> It has been the default in the codebase for a few years. We changed the
> default on the 1.7 branch. You should have been using it.
>
>> I know there have been some ra_serf bugfixes since
>> 1.7, but there are certainly still some important open issues
>
> There is a single open issue that I believe warrants a fix for 1.8, and that
> is the HTTP/1.0 proxy work. That has been tested with a pre-release build of
> serf 1.1 for a new API. Before releasing that, I'm waiting on some feedback
> from Apache OpenOffice, which won't arrive until after they get past the
> insanity of their release this week. So when 1.1 is released, then I'll
> enable the code to fix the proxy issue (it's in there, just not
> fully-enabled).
There is the list of issues on roadmap.html (currently 7 issues). But
a bit more accurate is simply querying the bug database for
component==libsvn_ra_serf. That currently shows 17 issues. Definitely
not all blockers, but certainly more than one (anything that really
breaks some normal operations, basically).
>> (not to
>> mention unkown problems because ra_serf hasn't had enough coverage and
>> problems aren't always adequately reported).
>
> All software has unknown problems. I don't believe there are any more in
> ra_serf than any other code. If you believe otherwise, then start filing
> issues.
Sure, sure, we can't fix what we don't know, I get that. I'll readily
admit that I'm not doing enough to track down certain problems, and
file adequately documented issues about them. It's not always easy to
spend time on that during day-to-day work. It's tempting to just flip
a switch and retry with neon, and get on with what you actually wanted
to do...
Anyway, that's a bit the point of this post: I / we haven't been doing
enough to find bugs (by using serf and investigating things), and
pinpointing these issues.
>>
>> If we want to make serf happen for 1.8, shouldn't we (as a community)
>> spend more time on it then?
>
> Everybody already should have been doing this for years.
Yeah, *should have*. But we (or at least I) mostly haven't.
>> I'd hate for us to end up in the same
>> difficult situation as with the 1.7 release: trying to make it the
>> default but then realizing shortly before release that it isn't stable
>> enough (partly because it hadn't seen enough coverage, and people
>> didn't report problems so they could be fixed etc, etc...). In spite
>> of the request in the 1.7-release notes for users to try out serf and
>> report problems [1], I haven't seen many new reports ...
>
> Because maybe it works? Ever consider that?
Of course that's a possibility. But I sincerely doubt that. It's a lot
more likely that (ra_)serf, like any software, contains a reasonable
amount of bugs, some of which will only be discovered by increased
usage in different environments.
I know it's a bit of a chicken and egg problem (we need more exercise
so we can find and fix more bugs so we can make it the default so it
can get more exercise ...). So we definitely will have to "jump"
someday. All I'm asking is: have we done enough to be sufficiently
confident to make that jump?
>>
>> I think we need some kind of community decision whether or not we'll
>> go for it this time.
>
> When we went with neon for 1.7, we said serf for 1.8. Do you have any
> concrete information to change that choice?
Well, not really. But it worries me that not much seems to have
changed between then and now. Maybe I'm wrong (certainly some things
have been fixed/improved, and if you're close to fixing the proxy
thing, that's definitely a big one). It doesn't hurt to double check
that we've really got it into good-enough-to-be-default state this
time, does it?
>> And if we go for ra_serf as the default, put much
>> more effort into it to make it happen. Starting with agreeing on a set
>> of requirements that we want to be satisfied before release, or
>> something like that.
>
> Requirements are fixing the 1.8 blocking issues. I say there is just the
> proxy one, which is mostly done.
And:
3981 (serf infinite loop over https)
3993 (serf corrupts wc by calling close_edit for an incomplete update-report)
4008 (URL-URL copy fails due to "unsupported feature")
4088 (assertion failure when using serf instead of neon RA.)
4106 (serf checkout fails on XML escaped property names)
(and maybe others, depending on what one considers blocking)
>>
>> FWIW: I personally think serf brings noticeable (performance)
>> improvements for users (so it's not only a license/developer/...
>> thing) [2]. But it's hard to measure, it depends on a lot of factors,
>> and can differ between usecases. On the downside: it's not yet stable
>> enough,
>
> Why do you say it is not stable enough? Unfiled issues?
>
>> and generates too many requests (generating too many logs on
>> the server).
>
> That is not a real-world issue, IMO. I have never heard a user complain,
> ever, about the sizes of logfiles produced by the Apache HTTP Server, in the
> 13.5 years I have been associated with the project. Do you have any cases
> where people have complained?
>
>> So I still see ra_serf having a lot of potential, and I
>> hope it will become the default one day...
>
> It is already the default.
Not in any released version.
>>
>> --
>> Johan
>>
>> [1] http://subversion.apache.org/docs/release-notes/1.7.html#serf
>>
>> [2] On a Solaris build machine @work (Solaris 10 on x86 on ESX, with
>> 1.6.17 client, 1.5.4 server (sorry, old stuff)), most interactions
>> with the svn server are a lot faster when using serf than with neon.
>> Things like ls, cat, log, mergeinfo, ... are all a lot faster (like
>> 150ms vs. 900ms).
>
> Upgrading your server will enable the faster HTTP sequences in both layers.
> It might narrow that gap.
>
>> Unfortunately, I can't use serf in general, because
>> checkouts and updates crash sometimes (yeah, I need to investigate
>> more, and report those ... first need to reproduce with a 1.7 client
>> ...).
>
> Filing bugs for both 1.6 and 1.7 are useful.
>
> Separately, if you can somehow get me (temporary/occasional) access to any
> Solaris box, that would be helpful. I have no access to one today.
Sorry, I can't. I can try some things on those boxes if you want, but
it's pretty limited (I can't even build svn on there, so it's hard to
try out custom things --- I mostly rely on the CollabNet builds, or
those from sunfreeware or opencsw etc).
>> So in my scripts I sprinkle "config-options
>> servers:global:http-library=serf" for all svn commands that I know
>> will not crash (basically anything except checkout, export and
>> update).
>
> How many files in your working copy / export? We had a large working set
> issue when these had tens of thousands of nodes. Fixed in 1.7.
Sorry, I was handwaving a bit here. It's not really crashing currently
(I previously had crashes with serf, but that was with one of the 1.7
betas I believe, could be the issue you mention was fixed in 1.7). But
now it's erroring out with "svn: E730053: Error retrieving REPORT
(730053): An established connection was aborted by the software in
your host machine." That's with a 1.7.4 client on Windows and a 1.7.3
server also on Windows.
I'll file a proper issue for this (but not today, it's already past 2 am).
--
Johan
Received on 2012-05-03 02:12:31 CEST