httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Park <ronald.p...@cnet.com>
Subject RE: [PATCH] Review & Test: mod_include redesign
Date Mon, 18 Aug 2003 15:39:00 GMT
Our problems also only seem to occur in production (likely due
to increased bucketizing/brigadeering on a congested network),
but we'll try to get these into various QA environs to help shake
out any bugs.

Thanks,
Ron

> -----Original Message-----
> From: Glenn Nielsen [mailto:glenn@mail.more.net] 
> Sent: Sunday, August 17, 2003 10:00 PM
> To: dev@httpd.apache.org
> Subject: Re: [PATCH] Review & Test: mod_include redesign
> 
> 
> I am glad to see that work continues on  fixing bugs in 
> mod_include. :-)
> 
> The only place I have had problems is on two of our 
> production servers.
> I will have to wait until the mod_include patch is considered 
> ready for
> release (production) in the 2.0 branch before I would 
> consider upgrading
> and doing a production test.
> 
> Regards,
> 
> Glenn
> 
> André Malo wrote:
> > [CC to Ron Park and Glenn Nielsen to get this onto their radar]
> > 
> > Since it turned out that one segfault was hunting the next 
> and mod_include
> > became more and more unmaintainable, Brian Pane and I 
> started (independently
> > :) a rewrite of the filter parser. While Brian used the old 
> design and
> > external API (mostly for backwards compat) I've tried to 
> redesign it from
> > the scratch. However, we've finally decided to take the 
> newly designed
> > version.
> > 
> > The new code consists of a buffer centric parser (as 
> opposed to a brigade
> > centric one). There's just one main loop that knows about 
> buckets and the like
> > and passes most of the actual parser work to functions that 
> deal only with
> > buffers. The output is handled similar to mod_bucketeer; we 
> no longer insert
> > buckets somewhere in the currently parsed brigade, we just 
> create a new one
> > and append all new buckets at the end. From time to time 
> this one will be
> > passed down the filter chain. This results even in a 
> simpler -- though
> > incompatible -- external API. In order to be able to backport the
> > change(binary compatible), there are just some lines 
> wrapper code necessary
> > which emulate the old API.
> > 
> > The new code passes all tests, except one 
> (modules/include/#36), where I'd
> > say, we should change the expectation ;-)
> > (1.3 throws nothing in this test, the current mod_include 
> throws two error
> > messages and the new module throws just one error message).
> > 
> > I've uploaded all the code for review and test.
> > 
> > - plain code (for 2.1 HEAD)
> >       <http://cvs.apache.org/~nd/mod_include.c> (123K)
> >       <http://cvs.apache.org/~nd/mod_include.h> (5K)
> > 
> > - full patch against 2.1 (about 200K)
> >   It contains also patches of mod_cgi and mod_cgid (because 
> of the modified
> >   API) and some other neat things like namespace protection 
> of the public
> >   parts etc. - but don't worry, once I'm committing it, 
> it'll we splitted into
> >   several commits.
> >       <http://cvs.apache.org/~nd/ssi-redesign21.patch>
> > 
> > - full patch against 2.0 (about 70K)
> >   This patches only mod_include.c and mod_include.h and 
> only the parts that
> >   are necessary to get it working. It also contains the 
> wrapper code for
> >   binary compat.
> >       <http://cvs.apache.org/~nd/ssi-redesign20.patch>
> > 
> > Please have a look at it. Opinions, comments etc are highly 
> appreciated.
> > Thanks.
> > 
> > nd
> 
> 

Mime
View raw message