On 20 April 2012 13:52, James Brown <[email protected]> wrote:
> Responses inline:
>
> On Thu, Apr 19, 2012 at 7:59 PM, Graham Dumpleton
> <[email protected]> wrote:
>>
>> First off, the bucket brigade will be cleaned up in as much no memory
>> will leak because of how Apache memory pooling works.
>
>
> I mostly changed it because that is how I've seen other apache modules do
> it. I'll believe you if you say that the brigade won't leak. I hate reading
> APR documentation
It looks to be one of those things which is harmless to call if an error.
APU_DECLARE(apr_status_t) apr_brigade_cleanup(void *data)
{
apr_bucket_brigade *b = data;
apr_bucket *e;
while (!APR_BRIGADE_EMPTY(b)) {
e = APR_BRIGADE_FIRST(b);
apr_bucket_delete(e);
}
/* We don't need to free(bb) because it's allocated from a pool. */
return APR_SUCCESS;
}
APU_DECLARE(apr_status_t) apr_brigade_destroy(apr_bucket_brigade *b)
{
apr_pool_cleanup_kill(b->p, b, brigade_cleanup);
return apr_brigade_cleanup(b);
}
At the moment it would be getting picked up when the pool calls
apr_brigade_destroy() on the pool being destroyed.
>> As for whether messages, when yielding response from an application,
>> either way a message is going to end up in the logs and nothing more.
>> Your issue therefore seems to be the log level of messages in logs and
>> your wanting to hide them as much as possible.
>>
>> My recollection of why it is done the way it is is that an error at
>> that point can actually indicate a problem in the Apache output filter
>> chain and doesn't just mean that an error occurred in sending data to
>> the client. Unfortunately mod_ssl seems to indicate errors when issue
>> was a closed client connection because SSL will flag an error if in
>> middle of some SSL exchange.
>>
>> In other words, one should necessarily be masking what could be a true
>> actual error or problem rather than just noise. I would really need to
>> try and find old emails about this as has been discussed before.
>
> It could be an actual problem. But, in practice over an enormous number of
> requests, it seems to happen almost any time a client disconnects mid-write
> (and, no, we're not using mod_ssl), and having all of these errors in our
> log was actually masking more actual problems than hiding them would. If
> nothing else, it would be nice to make there be a configuration flag to
> avoid printing enormous amounts of this spam for configurations where we
> know there's nothing interesting farther down the filter chain.
I will have a bit more of a look at it and think about. Timing is
certainly good as just last weekend did first bit of serious work on
mod_wsgi for a long time, even if was only back porting stuff from 4.0
development version so could release a mod_wsgi 3.4 some time soon.
Graham
--
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en.
