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

[Jack Repenning <jr...@collab.net>]

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