[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Flushes in httpd was Re: timeout mysteries SOLVED! (was Re: Large Repositories)

From: Jack Repenning <jrepenning_at_collab.net>
Date: 2003-07-15 18:54:20 CEST

At 2:26 AM -0700 7/15/03, Justin Erenkrantz wrote:
>Either ap_filter_flush is a valid solution, or it should be removed
>entirely. You can't have it both ways. Requiring the addition of
>custom threshold code to *every* filter is a cumbersome requirement.
>If you really feel that's needed, then we should remove flush
>support to compensate. -- justin

Well, it might be that this, in turn, is a tad overboard. The
established conventions for network protocols are pretty highly
optimized and nuanced, with clear and unremovable roles for all these
pieces. Transports should certainly deliver data; they're encouraged
to batch the delivery for efficiency, but they're also responsible to
send the data sooner or later. Clients, on the other hand, should
not have to think about line discipline for the most part, but there
are occasions when this is necessary.

In this case, it sounds like there's a fundamentally message-based
service layer, waiting for its packet to be delivered and a response
to arrive, but using a fundamentally stream-based transport (which is
still waiting for enough data to make the send worthwhile). Do I
read that right? If so, that kind of core-algorithm mismatch is one
of the reasons for flush calls in the APIs.

Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 15 18:55:37 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.