httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <...@covalent.net>
Subject Re: file/mmap buckets, subrequests, pools, 2.0.18
Date Wed, 06 Jun 2001 15:56:31 GMT
On 6 Jun 2001, Jeff Trawick wrote:

> <rbb@covalent.net> writes:
>
> > > Note that with a simple situation I just recreated, the mmap bucket
> > > for a small file is being held by the content-length filter (it did
> > > ap_save_brigade).
> > >
> > > I'm confused...  What would ap_sub_req_output_filter() be able to do
> > > to help?
> >
> > That depends.  Was this a sub-request?  If so, then when the
> > sub_req_output_filter was called, it would have converted the mmap bucket
> > into a heap bucket.  If this wasn't a sub-request, then you don't really
> > have a problem.  The only time this should still be a problem, is if the
> > file is >9k, and for some reason we didn't stream it.  I can't think of
> > when that would happen though.
>
> The file/mmap bucket was created for a sub-request by handle_include.
> Here is the backtrace from when we get to ap_content_length_filter:
>
> #0  ap_content_length_filter (f=0x42089014, b=0x42093014) at
>  protocol.c:853
> #1  0x80b60bf in ap_pass_brigade (next=0x42089014, bb=0x42093014) at
>  util_filter.c:242
> #2  0x807751d in ap_byterange_filter (f=0x42088014, bb=0x42093014) at
>  http_protocol.c:2263
> #3  0x80b60bf in ap_pass_brigade (next=0x42088014, bb=0x42093014) at
>  util_filter.c:242
> #4  0x806c61d in send_parsed_content (bb=0xbfff8e58, r=0x42065014,
>  f=0x42087014) at mod_include.c:2601
> #5  0x806ccab in includes_filter (f=0x42087014, b=0x42093014) at
>  mod_include.c:2770
> #6  0x80b60bf in ap_pass_brigade (next=0x42087014, bb=0x42093014) at
>  util_filter.c:242
> #7  0x80c0049 in ap_sub_req_output_filter (f=0x4206a014,
>  bb=0x42093014) at request.c:813
> #8  0x80b60bf in ap_pass_brigade (next=0x4206a014, bb=0x42093014) at
>  util_filter.c:242
> #9  0x80bdc7c in default_handler (r=0x42065014) at core.c:2995
> #10 0x80a8c71 in ap_run_handler (r=0x42065014) at config.c:133
> #11 0x80a938e in ap_invoke_handler (r=0x42065014) at config.c:292
> #12 0x80c0b3d in ap_run_sub_req (r=0x42065014) at request.c:1100
> #13 0x806868b in handle_include (ctx=0x4204e014, bb=0xbfffd4b8,
>  r=0x41fe5014, f=0x42040014, head_ptr=0x81309a0,
>  inserted_head=0xbfffd448)
>     at mod_include.c:850
> #14 0x806c2bd in send_parsed_content (bb=0xbfffd4b8, r=0x41fe5014,
>  f=0x42040014) at mod_include.c:2516
> #15 0x806ccab in includes_filter (f=0x42040014, b=0x42082014) at
>  mod_include.c:2770
> #16 0x80b60bf in ap_pass_brigade (next=0x42040014, bb=0x4204c014) at
>  util_filter.c:242
> #17 0x80bdc7c in default_handler (r=0x41fe5014) at core.c:2995
> #18 0x80a8c71 in ap_run_handler (r=0x41fe5014) at config.c:133
> #19 0x80a938e in ap_invoke_handler (r=0x41fe5014) at config.c:292
> #20 0x80788f1 in process_request_internal (r=0x41fe5014) at
>  http_request.c:378
> #21 0x8078a37 in ap_process_request (r=0x41fe5014) at
>  http_request.c:444
> #22 0x8073543 in ap_process_http_connection (c=0x41fdb014) at
>  http_core.c:280
> #23 0x80b4811 in ap_run_process_connection (c=0x41fdb014) at
>  connection.c:82
> #24 0x80b4a38 in ap_process_connection (c=0x41fdb014) at connection.c:216

So yeah, if we added the logic to the sub-req-output-filter to do the
conversion, this problem would be solved.  The logic is already in
core_output_filter, it's just a simple copy and paste.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message