Aaron Bannert wrote:
>On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote:
>
>
>>It's
>>unreasonable to make the every admin responsible for hacking
>>their start scripts to work around our broken product.
>>
>>
>
>In what way is our product broken?
>
Well, threaded MPMs or large vh
On Mon, 15 Jul 2002, William A. Rowe, Jr. wrote:
> At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>
> >BTW, this whole conversation started because we wanted to speed up
> >Apache. Has anybody considered taking a completely different tack to
> >solve this problem?
> >
> >I know there is a patent on t
At 10:03 PM 7/14/2002, Ryan Bloom wrote:
>BTW, this whole conversation started because we wanted to speed up
>Apache. Has anybody considered taking a completely different tack to
>solve this problem?
>
>I know there is a patent on this, but I am willing to ignore it, and I
>am pretty sure that w
On Sun, Jul 14, 2002 at 09:09:46PM -0700, Brian Pane wrote:
> It's
> unreasonable to make the every admin responsible for hacking
> their start scripts to work around our broken product.
In what way is our product broken?
In order to use our product in certain ways your system may have
to be con
Aaron Bannert wrote:
>I really don't like this. It adds unnecessary complexity to the configure
>script,
>
There's nothing unnecessary about it.
> misleads admins in to thinking that they have to rerun configure
>to set the file limit,
>
No, nowhwere do we say "you have to rerun configure to s
I really don't like this. It adds unnecessary complexity to the configure
script, misleads admins in to thinking that they have to rerun configure
to set the file limit, and does something that should just be set by
the admin themselves at starttime.
-aaron
On Sun, Jul 14, 2002 at 11:18:46PM -0
Graham Leggett wrote:
> Ok... worker is threaded? (I don't know my MPM's, been focusing on the
> other modules).
Yes, worker is threaded. But I was wrong - it has the same problem as
with prefork. I think I was not as brutal the first time I tested with
worker; see below.
>> Connections accum
Ryan Bloom wrote:
>>From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
>>
>>At 02:51 AM 7/14/2002, you wrote:
>>
>>
>>>Currently, the content-length filter attempts to compute the length
>>>of the entire response before passing any data on to the next filter,
>>>and it sets request_rec->by
> From: William A. Rowe, Jr. [mailto:[EMAIL PROTECTED]]
>
> At 02:51 AM 7/14/2002, you wrote:
> >Currently, the content-length filter attempts to compute the length
> >of the entire response before passing any data on to the next filter,
> >and it sets request_rec->bytes_sent to the computed cont
At 02:51 AM 7/14/2002, you wrote:
>Currently, the content-length filter attempts to compute the length
>of the entire response before passing any data on to the next filter,
>and it sets request_rec->bytes_sent to the computed content-length.
The real answer is simple. C-L filter should only set
At 02:51 AM 7/14/2002, you wrote:
>Currently, the content-length filter attempts to compute the length
>of the entire response before passing any data on to the next filter,
>and it sets request_rec->bytes_sent to the computed content-length.
>
> * r->bytes_sent is used by mod_log_config as a co
On Sun, 2002-07-14 at 09:35, Cliff Woolley wrote:
> On Sun, 14 Jul 2002, Brian Pane wrote:
>
> > For example, given a .shtml file that includes several small,
> > non-parsed files, the setaside logic in the C-L filter will do
> > an mmap+memcpy+munmap of each of the included files.
>
On Sun, 14 Jul 2002, Brian Pane wrote:
> For example, given a .shtml file that includes several small,
> non-parsed files, the setaside logic in the C-L filter will do
> an mmap+memcpy+munmap of each of the included files.
All that needs to happen here is that file_bucket_setaside()
Currently, the content-length filter attempts to compute the length
of the entire response before passing any data on to the next filter,
and it sets request_rec->bytes_sent to the computed content-length.
This is bad for several reasons:
* The C-L filter needs to know the length of every buck
14 matches
Mail list logo