axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <>
Subject Re: thoughts re development towards 1.0
Date Sat, 02 Dec 2006 01:50:00 GMT
I have figured out why it did not segfault for me.
Now when I do the fix, it segfaults. Now I do understand the real need 
for a separate global pool. I am trying to fix that next.


Samisa Abeysinghe wrote:
> 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:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message