<br><font size=2><tt><br>
> I am now working on issue #1662.</tt></font>
<br><font size=2><tt>GREAT!</tt></font>
<br>
<br><font size=2><tt>> ...<br>
> BTW: Benedikt, what did you use, if you did, to trace memory leaks?<br>
> </tt></font>
<br>
<br><font size=2><tt>1. I used "top" to watch the size of the
process.</tt></font>
<br><font size=2><tt> (I think this doesn't help you to break
the problem down)</tt></font>
<br><font size=2><tt>2. I tried to work with mcheck. (At that time you
was "involved" by giving a tip ...)</tt></font>
<br><font size=2><tt> I made it run to produce this mcheck
output. I spent effort in analyzing the </tt></font>
<br><font size=2><tt> mcheck-outputfile. At the end it wasn't
helpful. I forgot the reason. </tt></font>
<br><font size=2><tt>3. Here in my company I have access to rational purify
on Windows.</tt></font>
<br><font size=2><tt> With the approach you described in bug#1664
you will end up with a small(!) </tt></font>
<br><font size=2><tt> C-program. Maybe I could analyze this
program with purify. </tt></font>
<br><font size=2><tt> (BUT: The project where I worked with
mapserver is over. So</tt></font>
<br><font size=2><tt> it is a problem for me to find time
and I don't want to promise </tt></font>
<br><font size=2><tt> anything to be done "in time".
But I'd *like* to do so ...)</tt></font>
<br>
<br><font size=2><tt>Benedikt</tt></font>
<br><font size=2><tt> <br>
> Regards,<br>
> Umberto<br>
> <br>
> On 2/13/06, Umberto Nicoletti <umberto.nicoletti@gmail.com>
wrote:<br>
> > On 2/13/06, umn-ms@hydrotec.de <umn-ms@hydrotec.de> wrote:<br>
> > ><br>
> > > Umberto<br>
> > ><br>
> > > Thank you for taking care onon this old but still open issue!<br>
> > ><br>
> > > I created<br>
> > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1661 and<br>
> > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1662<br>
> > ><br>
> > > Benedikt<br>
> > ><br>
> > > (Sorry! I was not able to add your e-mail-adress to cc.
Bugzilla denied to<br>
> > > do so. I suppose<br>
> > > you can handle this anyway.)<br>
> ><br>
> > I just did. I will send you a patch for the<br>
> > msConnPoolCloseUnreferenced function asap o that you can test
it.<br>
> ><br>
> > Regards,<br>
> > Umberto<br>
> ><br>
> > ><br>
> > > Umberto Nicoletti <umberto.nicoletti@gmail.com> schrieb
am 13.02.2006<br>
> > > 10:25:02:<br>
> > ><br>
> > ><br>
> > > > Benedikt,<br>
> > > > since I am looking this issue would'n t you mind
opening a bug for the<br>
> > > > inclusion of msConnPoolCloseUnreferenced in mapscript
and one for the<br>
> > > > memory leaks (add me to the cc list)?<br>
> > > ><br>
> > > ><br>
> > > > Reagrds,<br>
> > > > Umberto<br>
> > > ><br>
> > > > On 1/2/06, Benedikt Rothe <umn-ms@hydrotec.de>
wrote:<br>
> > > > ><br>
> > > > > Hi list members,<br>
> > > > ><br>
> > > > > From former threads I got the impression,
that there are some folks<br>
> > > > > interested in the Oracle/Mapserver/Java/Tomcat.<br>
> > > > ><br>
> > > > > Therfore I'd like to share experiences I
made with using<br>
> > > Connection-Pooling<br>
> > > > > of<br>
> > > > > Oracle-Connections inside Java/Tomcat.<br>
> > > > ><br>
> > > > > Testenvironment: Mapserver 4.6.2; Suse-Linux;
Tomcat 4.1.31; Sun-Java<br>
> > > 1.4.2<br>
> > > > > Simulating 5 Browsers, which produce maps,
query features, make<br>
> > > selections,<br>
> > > > > query-legend-pics frequently.<br>
> > > > ><br>
> > > > > - After using synchronized "enough"
I didn't have crashes of Tomcat.<br>
> > > > ><br>
> > > > > - Big memory leak: Between the first 5 requests
and the next 100<br>
> > > requests<br>
> > > > > the Tomcat-process became about
400MB bigger. (I use "top" for<br>
> > > > > watching memory-footprint.)<br>
> > > > ><br>
> > > > > - Cleaning the Connection-Pool "by
hand". This means:<br>
> > > > > Opening the function msConnPoolCloseUnreferenced
in mappool.c<br>
> > > > > for use in Java and call it after
every request.<br>
> > > > ><br>
> > > > > - After this I still have memory leaks:
About 100MB for 30.000<br>
> > > requests.<br>
> > > > > (I also made a test: 25.000 requests
without Connection pooling.<br>
> > > Memory<br>
> > > > > increased<br>
> > > > > and decreased as expected
in this case.)<br>
> > > > ><br>
> > > > > - Performancecomparison in my testcase:<br>
> > > > > Without use of connection-pooling:
~ 50 Request per minute<br>
> > > > > With use of connection-pooling: ~75
Request per minute<br>
> > > > ><br>
> > > > ><br>
> > > > > As a result I have the following encouragements:<br>
> > > > > - Making msConnPoolCloseUnreferenced availabe
for mapscript via swig.<br>
> > > > > (I made a hack by directly editing
mapscript/java/mapscript_wrap.c<br>
> > > and<br>
> > > > > Java-Files in<br>
> > > mapscript/java/edu/umn/gis/mapscript.) I<br>
> > > > > think this<br>
> > > > > function could be part of the mapscript-Object?<br>
> > > > ><br>
> > > > > - Investigations on the memory leaks. Both
leaks shouldn't occure.<br>
> > > (I'll do<br>
> > > > > this, if I find time. but ...)<br>
> > > > ><br>
> > > > > - Fernando Simon: What about using OCI-Connection-Pooling
for oracle<br>
> > > > > instead the mappool.c?<br>
> > > > ><br>
> > > > ><br>
> > > http://oraclesvca2.oracle.com/docs/cd/B14117_01/appdev.101/b10779/oci09adv.htm#452244<br>
> > > > > (If you don't have time, I maybe
could help coding. But would it<br>
> > > become<br>
> > > > > part uf Mapserver?)<br>
> > > > ><br>
> > > > > Happy new year to everybody<br>
> > > > > Benedikt Rothe<br>
> > ><br>
> ><br>
</tt></font>