axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <sam...@wso2.com>
Subject Re: thoughts re development towards 1.0
Date Thu, 30 Nov 2006 14:58:11 GMT
Hi Chris,
    I had a second look into your patch, and if I understand your patch 
correct, in the axis2_handler function of mod_axis2.c, you set the 
environment's pool to request pool before asking the worker to process 
the request:
axis2_env->allocator->data = (void*) req->pool;

Given that, I am wondering why there is a memory growth. Could you 
please help me understand this?

Thanks,
Samisa...
   
Samisa Abeysinghe wrote:
> Hi Chris;
>>    The attached patchset is a first hack at making mod_axis2 use
>> these two kinds of pools.  It works, sort of, but after a few
>> requests the child processes segfault.  (It doesn't include
>> patches to rampart or guththila, both of which seems to contain
>> a few calls to AXIS2_REALLOC which would need to be rewritten.)
>> The segfaults always seems to happen at the following level of
>> the calling stack (for me, anyway):
>>   
> I applied your patch to the latest svn head today (but did not commit 
> yet)
> I am not getting any seg fault as you have mentioned. However, i am 
> noticing considerable memory growth. This must be due to the fact that 
> this patch does not use a separate allocator per request.
>> 1) Add to the env structure a second allocator, named something like
>>    resident_allocator or config_allocator or something.
>> 2) Analyze which data structures in Axis2/C were effectively
>>    "configuration" data and needed to stay in memory for the lifetime
>>    of a process.  This should include any such data that needs to
>>    be modified or deleted over the lifetime of the server process.
>> 3) For each such structure, ensure that it is created, modified,
>>    and deleted using only the env->resident_allocator.  This could
>>    be accomplished a variety of ways (a private sub-allocator,
>>    for example).  The main concern is thread-safety; if multiple
>>    threads might be managing this structure at the same time,
>>    a thread mutex will need to be used as well.
>>
>>    At this point, everything else should be data which can be
>> cleaned up automatically when the httpd request->pool is cleared
>> at the end of each HTTP request.  
> I hope when we do this, the memory growth would come under control.
> However, some effort is required to differentiate between 
> configuration data versus per request data. (Well, the description 
> hierarchy and some parts of the configuration hierarchy have long 
> life. However, these may be mixed up with per request stuff.)
>
>> Then you could even go through
>> the code and remove all the calls to AXIS2_FREE() if you really
>> felt like it!  
> Well, to do this, we also have to ensure that we have a proper pool in 
> place to be used with simple axis server.
>> The key advantage is that it means that each
>> httpd server process is guaranteed to only increase in size if
>> the "configuration" data grows, and this should presumably be by
>> only a trivial amount.
>>   
> Agreed.
>>    What I might propose is a compromise, since clearly the function
>> pointer technique is used extensively and can't just be replaced.
>> Here are my proposals:
>>
>> 1) AXIS2_ENV_CHECK() and AXIS2_PARAM_CHECK() should call
>> AXIS2_LOG_ERROR() in the case where the argument is NULL.  Because
>> these are macros they'll expand so that AXIS2_LOG_SI gives file
>> and line information on the place where the NULL argument was
>> encountered.
>>
>> 2) All the macros that perform indirect function calling through
>> the many ops structures should be expanded to first call
>> AXIS2_ENV_CHECK() and AXIS2_PARAM_CHECK() on their key env
>> and "interface" structure pointer arguments.  It might be good
>> to also check for a NULL ops structure pointer and a NULL function
>> pointer in the ops structure.
>>   
> I am yet to try these suggestions. Anyway, it looks to me that we have 
> to get rid of the macros and ops indirection altogether.  And yes, it 
> will obviously take considerable time and effort. So lets try these 
> suggestions for 1.0 time frame.
>
>
> Thanks,
> Samisa...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message