Alex Bolgarov wrote:
Samisa, thank you; I checked out the SVN trunk version, build it and
run the test again.
On the server side (mod_axis2) there is no more memory leaks: I run
the test with 100000 iterations, it took 4 minutes, httpd process
memory usage is stable and is not increasing.
But now there is a memory leak on the client side. I noticed that my
modified echo client (I modified the sample code to run the requests
in a loop) increases the memory usage all the time.
Then I compiled the original, unmodified echo.c sample from the
samples/client/echo directory, and run it through the valgrind. I'm
attaching the valgrind's log file; in a hope that this will help to
fix this. According to the valgrind log, there is a 6K bytes that
valgrind decided are 'definitely lost'.
I did not run valgrind recently on my machine, however, in 1.2, it used
to hit 0. May be there is a new leak added due to changes. I am right
now on Windows, and would check this when I get a chance. In the mean
time, please send the valgrind log.
Samisa...
Thank you,
alex.
On Tue, Apr 8, 2008 at 9:21 AM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
Local pools have been integrated to mod_axis2 in Axis2/C trunk.
You may run the tests again and see the improved memory footprint.
Samisa...
Samisa Abeysinghe wrote:
Alex Bolgarov wrote:
On Mon, Mar 31, 2008 at 11:17 PM, Uthaiyashankar <[EMAIL PROTECTED]>
wrote:
I doubt whether it is a memory leak. When using mod_axis2, memory
management is done by apache apr. Memory is released only when pools
are
destroyed. Memory will not be released when calling AXIS2_FREE.
(axis2_module_free is implemented in mod_axis2.c:412 and it is an
empty
method unless the pool associated with is global shared pool).
Well, we can of course discuss the meaning of a term 'memory leak',
but what happens here is awfully close to any sensible definition :)
Thank you for pointing out that the mod_axis2 does not really release
memory by design.
What we are using is APR model of pools. So you cannot say that we are not
releasing memory by design. We are depending on APR pools to release memory
by design.
We have looked deep into this issue in the past, and proven that the
request pool is reclaimed by main pool upon request completion.
How do you think what happens if I change the
allocator used by mod_axis2 to use malloc()/free(), not the APR's
apr_pool_...() functions? Will the memory leak go away?.. Actually,
this is exactly what I'm going to do. I have some experience in
developing Apache httpd modules, and I write them in C++ and freely
use new/delete operators, so I know that using a memory allocator
other then APR's pool functions in the httpd process is OK.
If you go and discuss this with httpd or apr list, they will sure tell you
that this is the wrong way to do that.
There are better ways of doing this, like using using local pools, which
we are going to implement soon.
Samisa...
I will
report my findings here, hopefully in a couple of days.
Thank you,
alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Samisa Abeysinghe Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.10/1366 - Release Date: 4/8/2008 5:03 PM
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
