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 Sun, 03 Dec 2006 01:09:20 GMT
Chris Darroch wrote:
> Samisa:
>> I gave it a try and it seems to work. What I did was is to place the 
>> whole of description hierarchy and part of the context hierarchy, 
>> starting from operation context and upwards (that is op_ctx, svc_ctx, 
>> svc_grp_ctx and conf_ctx) in to global pool. The rest is in the request 
>> pool and the trick seems to work. Not the ideal solution but we can use 
>> this as our starting point I hope.
>> What I would do is that, I would test this a bit more, ensure that it 
>> does not crash in an ad-hoc manner and then commit the stuff.
>> Once committed, if you could give it a try again and let us know the 
>> status, that would be great. In the latest fix, in addition to your 
>> patch, I have also introduced a global pool to the allocator as you had 
>> suggested earlier. I would let you know, once I commit the stuff.
>    Cool, thanks!  Yes, please give me a ping -- private email is good,
> too, to make sure I see it! -- when you've got a patch ready to try.
I have committed the patch to svn. Also added some logic to switch 
between local and global pool for memory allocation in allocator. The 
only place this logic being used now is in 
modules/core/engine/ctx_handler.c, where we build the context hierarchy 
up to operation context. In my tests with httpd, I noticed that even 
though memory grows, it drops after some time.
Many thanks to Chris for the patch and thoughts on how to address the 
Please let us know the results of your tests.
>    One note, BTW -- I rewrote a couple of places where AXIS2_REALLOC()
> was used in the main codebase, enough for me to get started, but as I
> noted somewhere (in Jira, I think) there are a few other uses of it that
> would need rewriting in general.  Rampart has a few, I think, for
> instance.  Overall there are thankfully very few instances of it.
Agreed, would raise a Jira on this.

> Chris.

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

View raw message