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 10:00:01 GMT
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


Mime
View raw message