On Wed, Nov 05, 2003 at 07:18:30PM +0100, Sander Striker wrote:
> > From: cmpilato@localhost.localdomain
> > [mailto:cmpilato@localhost.localdomain]On Behalf Of C. Michael Pilato
> > Sent: Wednesday, November 05, 2003 7:09 PM
>
> > > What if we were to do the deltification on the same thread that serviced
> > > the request, but after the response has been written to the socket?
> >
> > This was my original idea, but there's an API problem. I don't
> > believe that Apache guarantees that things we write to our output
> > stream are flushed to the socket immediately. The *right* way to do
> > this would be for Apache/mod_dav to provide a post-request cleanup
> > hook, which is guaranteed to run only after the request response has
> > been sent down the wire. In that cleanup, we could do the
> > deltification.
> >
> > But if Apache doesn't have this functionality already, we don't have
> > time to wait for another release of that code.
>
> You can do a forced flush.
Euh... please, no. We really don't want to get into the business of
monkeying with what Apache decides is the proper behavior for delivery of
data to the socket.
As Justin pointed out, putting a clean on the request pool might work out.
However, that *does* imply that other request cleanups could be delayed,
and it also delays a return to Apache to deal with the connection object.
In particular, we want to return control to Apache so that it can process
the DELETE request which directly follows the MERGE request.
The cleanup really ought to be on the connection object so that we don't
slow down request processing. But even that is a bit shaky, as we don't
know the relative ordering of the deltification against the closure of the
socket. It would suck to see Apache decide to close the connection, but a
client doesn't know that is happening until several minutes later.
Meanwhile, they're hung up on sending another set of requests over the
connection, only to be delayed on knowing they have to close and reopen a
connection.
IMO, I like the idea of a fully out-of-band mechanism in the post-commit.
Alternatively, I would also like to see a "standard" script that does the
deltification and the log file pruning, and is intended to be run by cron
periodically. I would also suggest this script can be configured to handle
N repositories on the box, so that an admin can just tweak a .conf file
rather than setting up Yet Another Cron Entry.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 5 21:17:08 2003