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:[EMAIL PROTECTED] > Sent: Sunday, August 17, 2003 10:00 PM > To: [EMAIL PROTECTED] > 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 > >
