On Thu, 2003-12-11 at 16:30, Stas Bekman wrote:
Raul Dias wrote:
On Wed, 2003-12-10 at 20:42, Stas Bekman wrote:
Lastly, why does the memory continue to be consumer after the client has terminated the connection?
Because the server doesn't realize that the connection was aborted. You can check that with $c->aborted. It could also be a bug in Apache 2. I'd check whether it works without mod_perl, e.g. using INCLUDES or some other core filter with a big file.
So it would be nice to have this in the filter (at least) documentation.
why at least? what else did you have on your mind?
It would really help to have some section about all the methods available to $filter, $request and $connection handlers.
some section? You are being funny:
perl-5.8.3-ithread -MApache2 -MModPerl::MethodLookup -e print_object Apache::RequestRec | wc -l
149
This is only the methods you can invoke on the request object. There are some 600 or 700 methods and functions in mp2.
Things are slowly getting documented at: http://perl.apache.org/docs/2.0/api/
For example the filter page is pretty complete: http://perl.apache.org/docs/2.0/api/Apache/Filter.html
Most of the time I found some methods by browsing the list history. I just got to know about $c->aborted() in this thread.
Sorry if this is documented somewhere, but there is no mention of it by greping the docs dir.
Because it's incomplete. Help to add more things is very welcome. A big chunk is the same as mp1 so it should be an easy copy-n-paste.
So you did have it solve your problem? Very good.
In a bandwidth limiter it is very important to know that a connection is droped, so other clients can get the released bandwidth.
Absolutely.
Though I don't think Apache::DECLINED is the right return code here. Apache::DECLINED should be used when your filter decides not to filter the data, in which case mod_perl will forward the data to the next filter in chain. e.g. these two filters are equivalent:
sub out_filter { my ($f, $bb) = @_;
my $rv = $f->next->pass_brigade($bb); return $rv unless $rv == APR::SUCCESS;
return Apache::OK; }
sub out_filter { my ($f, $bb) = @_;
return Apache::DECLINED; }
I'm not sure what's the right response code to use here, since first it doesn't matter to the user (the connection is aborted), second a particual caller of the filter may ignore the response code. I'd think AP_FILTER_ERROR might be a good choice. Let me ask httpd-dev what response code should be used in such a case and I'll be back to you. Then we can document it nicely.
I think that Apache::DECLINED is the correct behaviour as you explain above.
In a bandwidth limiter, there is no point on holding the traffic after
the connection has being aborted.
You aren't holding the traffic. If the connection is aborted the process is still busy churning data, but it doesn't send any of it out. I don't think your bandwidth limiter should be affected at all. It should monitor sockets, not processes I believe. what if the process is busy in the cleanup phase, do you also consider it consuming bandwidth? It doesn't since Cleanup handler is run after the connection has been closed.
OTOH, a filter might need to finish parsing a file even if the connection was drop to do some clean up that might be dependent on the file content (e.g. a database transaction).
And that's precisely why I suggested that Apache::DECLINED is not the correct value to return, because of its special meaning. It'll try to forward the brigade that was already partially read and processed, which most likely mess things up (it doesn't since normally nobody cares what it does if the connection was aborted).
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
