I agree with both Greg Ames and Ryan. I would like to keep this fix in for now, even
though it is not perfect. It is certainly not nearly as bad as using c->pool. When the
setaside pool is ready, take it out. This keeps us working and able to debug other
problems in mod_include untill then. We may even be able to roll 2.0.19 late this week.
Bill
> [EMAIL PROTECTED] wrote:
> >
> > -1. We have discussed this on list multiple times. The solution is to
> > use the setaside pool argument that Greg Stein just added.
>
> includes have been totally broken since April 29. My patch fixes
> includes, so I believe
> this patch qualifies as making progress toward a usable server.
>
> I agree that the setaside idea has some merits, but it is slower for the
> common case
> (a few small files which turn into MMAPs) because it involves
> re-allocating and
> recreating the apr_blah_t structures. Shouldn't we be optimizing for
> the common cases
> rather than the basket cases?
>
> > This patch is
> > as bad as the original hack (using c->pool for files), because it creates
> > a huge resource leak. Imagine a simple SSI file with twenty small
> > included files, you just leaked 20 files until the end of the request.
>
> How huge are 20 apr_mmap_t's? Big deal if they have to wait for the end
> of the
> request. and how common would it be to have 20 include files anyway?
>
> I believe the patch which broke includes was attempting to handle the
> case where the little apr structures could stay around indefinately, due
> to keepalives. That doesn't happen with my patch.
>
> > This gets worse if the number of included files is larger, and other
> > modules may make the problem even worse.
> >
>
> Let's see some real world examples where this is noticeably bad.
>
> Remember, apache.org has been running fine for ages using the connection
> pool/lifetime for subrequests. I've removed any possible exposure to
> the keepalive problem by always using the main request lifetime.
>
> I would welcome a more elegant solution to the problem that actually
> works, and doesn't slow down the typical use of server side includes.
>
> Greg
>
