Axis2/C is becoming the most featured and stable and enterprise grade Web Services engine for C. Written in C, memory handling in Axis2/C is very crucial. This article written by Manjula Peiris discusses a few important tips related to memory management in Axis2/C. The article is recommended reading for Web service implementors, module writers and consumers of Web services in Axis2/C.

Table of Contents

1. Introduction to Axis2/C Memory Management Model [0]
2. Axis2/C with Apache2 [0]
3. A Few Important Memory Management Tips [0]
4. Summary [0]
5. References [0]

this manual [1] for more information on configuring Axis2/C with Apache2. When used with Apche2, there are certain factors that needs to be understood in relation to memory. When you deal with Apache the scopes of resources are different. To gain high performance and prevent memory leaks, Apache uses apr_pool concept. The following three pools are very important when using Axis2/C with Apache2.

Request pool

- Apache creates a pool for each request. All resources with the same life time as the request should be created in this pool. This is called the local_pool inside Axis2/C.

Process global pool

- In Apache, a single process may handle more than one request. So, for resources with a life time beyond that of the request, should be created in this pool. Please remember other processes do not have access to this pool.

System global pool

-This is called shared memory. Where all the processes have access to it. Resources with a scope, beyond process lifetime, need to be created here. You can specify whether to use System global pool or not. Adding the global pool size directive in the httpd.conf will do it.

For an example, the following directive will set a 10MB shared memory pool. If this is not added, or set to -1, then the shared memory pools will not be used.

Axis2GlobalPoolSize 10 

axutil_allocator.h defines two useful functions to switch between global and local pool. The default assumption is that everything is created in the local pool (request pool) . Therefore, in order to create some resource which has a lifetime beyond a single request a pool switch between local to global should be done. Calling following function will do it.

void axutil_allocator_switch_to_global_pool(axutil_allocator_t *); 

So if you have enabled system shared memory as explained above , all the calls to AXIS2_MALLOC now creates resources in the system global pool. And you can access the resources created in the global pool. If shared memory is not enabled then the resources will be created in process global pool. It is a must to switch to local pool when ever you do not need the resources in the global pool. Not doing this may cause memory leaks , because the resources which need to be freed after a particular request now not freed at that point. Calling following function will switch the pool to local pool.

void axutil_allocator_switch_to_local_pool(axutil_allocator_t *);

ws.apache.org/axis2/c/docs/axis2c_manual.html [2]

apr.apache.org/docs/apr/0.9/group__apr__pools.html [3]

Memory Management with Apache Axis2/C [4]

 

Author

Manjula Peiris is a Software Engineer at WSO2. manjula at wso2 dot com