On 10 Sep 2007 14:56:47 -0000, cmpilato@tigris.org <cmpilato@tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2916
> Issue #|2916
> Summary|Subversion is not always a good steward of its HTTP(S)
> | network connections
> Component|subversion
> Version|trunk
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|DEFECT
> Priority|P3
> Subcomponent|libsvn_ra
> Assigned to|issues@subversion
> Reported by|cmpilato
>
> ------- Additional comments from cmpilato@tigris.org Mon Sep 10 07:56:47 -0700 2007 -------
> Over in issue #2048, we dealt with a specific problem: Subversion sometimes
> spent so long doing stuff with secondary network connections (and simultaneously
> ignoring its primary connection) that the primary connection would time out,
> server-side. This was showing up in merge operations, especially those where
> contextual diff calculations and applications were especially time-consuming.
>
> But guess what -- it's not a merge-only problem. It's a general problem in
> Subversion, a somewhat natural-yet-unanticipated tension between the desire to
> do things streamily (avoiding front-loaded and back-loaded processing) and the
> need to suck data off of timeout-able sources at a sufficient rate.
>
> I've now observed this happening during 'svn update', with close_directory()'s
> WC log processing taking too long (for a directory with 928 files in it). I've
> suggested for some time that this might also pose problems in other areas, such
> as with interactive merge conflict handlers left unattended or an external merge
> tool taking too long to do its thang. But in general, *any* processing which
> occurs between network reads is a liability in this area.
>
> The obvious and universal fix is to always spool server responses to disk as
> they come down, and then read back the spool. (This was, in fact, the solution
> employed for issue 2048.) There are some similarly obvious cons to that
> solution, too (disk space usage, the perception of nothing happening until the
> spooling is done and the response is re-read from disk, extra I/O overhead,
> etc.) And these pros and cons vary depending on whether we are trying to spool
> a "full update" versus a "skelta"-type response.
You are aware that this approach can be enabled by changing one FALSE
to TRUE in libsvn_ra_neon, right? I mean, if this can pose a problem
like that, shouldn't we just do that? (Instead of filing this issue,
maybe even?)
HTH,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 10 16:59:08 2007