I am now working on issue #1662. Issue #1164 details how I am trying to tackle the memory leaks: with unit tests which run a significantly smaller portion of the code. In fact the ones in the patch run *only* the connection pooling functions, so it should be MUCH easier to use a debugger and trace them.
http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1664 BTW: Benedikt, what did you use, if you did, to trace memory leaks? Regards, Umberto On 2/13/06, Umberto Nicoletti <[EMAIL PROTECTED]> wrote: > On 2/13/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Umberto > > > > Thank you for taking care onon this old but still open issue! > > > > I created > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1661 and > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1662 > > > > Benedikt > > > > (Sorry! I was not able to add your e-mail-adress to cc. Bugzilla denied to > > do so. I suppose > > you can handle this anyway.) > > I just did. I will send you a patch for the > msConnPoolCloseUnreferenced function asap o that you can test it. > > Regards, > Umberto > > > > > Umberto Nicoletti <[EMAIL PROTECTED]> schrieb am 13.02.2006 > > 10:25:02: > > > > > > > Benedikt, > > > since I am looking this issue would'n t you mind opening a bug for the > > > inclusion of msConnPoolCloseUnreferenced in mapscript and one for the > > > memory leaks (add me to the cc list)? > > > > > > > > > Reagrds, > > > Umberto > > > > > > On 1/2/06, Benedikt Rothe <[EMAIL PROTECTED]> wrote: > > > > > > > > Hi list members, > > > > > > > > From former threads I got the impression, that there are some folks > > > > interested in the Oracle/Mapserver/Java/Tomcat. > > > > > > > > Therfore I'd like to share experiences I made with using > > Connection-Pooling > > > > of > > > > Oracle-Connections inside Java/Tomcat. > > > > > > > > Testenvironment: Mapserver 4.6.2; Suse-Linux; Tomcat 4.1.31; Sun-Java > > 1.4.2 > > > > Simulating 5 Browsers, which produce maps, query features, make > > selections, > > > > query-legend-pics frequently. > > > > > > > > - After using synchronized "enough" I didn't have crashes of Tomcat. > > > > > > > > - Big memory leak: Between the first 5 requests and the next 100 > > requests > > > > the Tomcat-process became about 400MB bigger. (I use "top" for > > > > watching memory-footprint.) > > > > > > > > - Cleaning the Connection-Pool "by hand". This means: > > > > Opening the function msConnPoolCloseUnreferenced in mappool.c > > > > for use in Java and call it after every request. > > > > > > > > - After this I still have memory leaks: About 100MB for 30.000 > > requests. > > > > (I also made a test: 25.000 requests without Connection pooling. > > Memory > > > > increased > > > > and decreased as expected in this case.) > > > > > > > > - Performancecomparison in my testcase: > > > > Without use of connection-pooling: ~ 50 Request per minute > > > > With use of connection-pooling: ~75 Request per minute > > > > > > > > > > > > As a result I have the following encouragements: > > > > - Making msConnPoolCloseUnreferenced availabe for mapscript via swig. > > > > (I made a hack by directly editing mapscript/java/mapscript_wrap.c > > and > > > > Java-Files in > > mapscript/java/edu/umn/gis/mapscript.) I > > > > think this > > > > function could be part of the mapscript-Object? > > > > > > > > - Investigations on the memory leaks. Both leaks shouldn't occure. > > (I'll do > > > > this, if I find time. but ...) > > > > > > > > - Fernando Simon: What about using OCI-Connection-Pooling for oracle > > > > instead the mappool.c? > > > > > > > > > > http://oraclesvca2.oracle.com/docs/cd/B14117_01/appdev.101/b10779/oci09adv.htm#452244 > > > > (If you don't have time, I maybe could help coding. But would it > > become > > > > part uf Mapserver?) > > > > > > > > Happy new year to everybody > > > > Benedikt Rothe > > >
