[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-httpd-bugs
Subject:    DO NOT REPLY [Bug 34589]  -
From:       bugzilla () apache ! org
Date:       2005-04-30 10:25:54
Message-ID: 20050430102554.DEAFC29C () ajax ! apache ! org
[Download RAW message or body]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=34589>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=34589





------- Additional Comments From norair@freenet.am  2005-04-30 12:25 -------
(In reply to comment #4)
> (In reply to comment #3)
> > It's more complicated than that because other filters higher up the chain will
> > split and leak a brigade for each FLUSH bucket sent, per bug 23567.

----------------quote from bug number 23567 thread------------------

Just brain-dumping, the design issue here is, per Jeff's analysis and subsequent
discussion:

1. brigades are allocated out of pools
2. every call to apr_brigade_split allocates a new brigade
3. every time a FLUSH bucket it sent down the filter stack, it causes at least
one call to apr_brigade_split

fixes for this could be either:

fix (1), allocate brigades out of the bucket-allocator so that they can really
be free'd (very intrusive since many filters presume brigades are never really
destroyed)

fix (3), adjust all filters to ensure that they don't allocate a number of
brigades per request (and hence, memory allocated) which is proportional to
number of FLUSH buckets sent.
----------------------------- end of quote--------------------


Look...

First change we had made is call apr_brigade_create from module code.
And we had played with following functions:

      apr_brigade_cleanup(bb);
      APR_BRIGADE_EMPTY(bb);
      apr_brigade_destroy(bb);

All attempts was unsuccessful...


Then we had attempt to make our module look like this:

int start_receive(request_rec *r, char* user_name, char* group_name)
{
        int ret;
        apr_bucket_brigade *bb = NULL;

        //added
        bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);

        ret = 1;
        ap_rprintf (r, "%s_%s:connected|%d\r\n", user_name, group_name, ret);
        ap_rflush2(r, bb);
             ... ... ...
and made some changes in server/protocol.c:

AP_DECLARE(int) ap_rflush2(request_rec *r, apr_bucket_brigade *bb)
{
conn_rec *c = r->connection;
apr_bucket *b;

//if(*bb==NULL){
//*bb = apr_brigade_create(r->pool, c->bucket_alloc);
//}

b = apr_bucket_flush_create(c->bucket_alloc);
APR_BRIGADE_INSERT_TAIL(bb, b);

//if (ap_pass_brigade(r->output_filters, bb) != APR_SUCCESS)
//return -1;

return 0;
}

So, even when apr_brigade_create function called from module and filters are
commented memory usage still growing.
I can mention, that when following lines
//if (ap_pass_brigade(r->output_filters, bb) != APR_SUCCESS)
//return -1;
are commented then memory usage grow too fast and can hang machine after few
seconds because of lack of resources.

We preferring to use Apache 2 instead of Apache 1.3 because of uncomparable
speed that is very important in our project : 'World Biggest Chat' by Lycos-Europe





-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]