httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@rexursive.com>
Subject Re: File buckets v. core_output_filter
Date Fri, 15 Aug 2003 07:01:09 GMT
One other thing I have forgotten to mention. The error log has this in it when
those buckets don't come out correctly:

[info] (70014)End of file found: core_output_filter: writing data to the network

If flush buckets are inserted, as I said before, the message goes away. This is
line 4206 of server/core.c.

Sidenote: On my system, emulate_sendfile seems to be used (RHL 9) in this whole
process. I'm pretty sure this version of Linux has sendfile support, not sure
why it is not used. Probably some other test in core_output_filter is making
sure of that.

Also worth noting is another interesting effect. First, I open up the file I
want to send out with apr_file_open. If I then obtain the file descriptor of it
(thanks Cliff!) with apr_os_file_get, dup it with dup(fd) and then
fdopen(fd,"r") it (huh!), I have another FILE pointer I can use for some other
stuff (i.e. scanning the file with Flex). However, this other use actually
brings the file position pointer to EOF. Given the dup() call, the postion of
the original file is also at EOF. If I don't have this:

rewind(fp);

just before this:

ap_pass_brigade(r->output_filters,bb);

in my code, I get nothing at all out (i.e. 0 bytes apart from headers) and the
above mentioned [info] in the error log (even with flush buckets). So, somehow,
somewhere core_output_filter code is getting upset by the fact that EOF was
reached, although that shouldn't make any difference given that the code for
sending file buckets out should position itself where needed in order to fetch
the appropriate data. Or at least that's what I think :-)

Hope this helps in debugging...

Quoting Cliff Woolley <jwoolley@virginia.edu>:

> On Sun, 10 Aug 2003, Bojan Smojver wrote:
> 
> > Just wanted to ask if you guys need me to open up a bug in Bugzilla for
> > this?
> 
> No need... I'll be looking at it tomorrow.  If it were going to be
> longer-term, I'd ask you to.  Thanks for the additional details and test
> module!
> 
> --Cliff
> 
> 


-- 
Bojan

Mime
View raw message