[fdo-internals] SDF 3.0 Memory Leak

[Traian Stanev]

Hi Carl.

It is every unlikely that there is such a large leak in the provider itself. The problem you are seeing is some interplay of the managed wrappers to FDO and your test code. In both cases, you would be seeing problems with all providers, not just SDF. Have you tried your test code with the SHP provider for example? Does it exhibit the same behavior?


Traian




> -----Original Message-----
> From: fdo-internals-bounces at lists.osgeo.org [mailto:fdo-internals-
> bounces at lists.osgeo.org] On Behalf Of Carl Jokl
> Sent: Friday, July 18, 2008 11:47 AM
> To: fdo-internals at lists.osgeo.org
> Subject: RE: [fdo-internals] SDF 3.0 Memory Leak
>
>
> As requested I am posting my response email on the thread for continued
> discussion. I have editied the response slightly for some company
> confidentiality reasons:
>
> Greg
>
> With all due respect I am not sure that this will make a difference.
> When
> you talk about memory usage falling to an acceptable level. The problem
> is a
> matter that the memory usage spirals upwards. It peaks higher than the
> ~340mb value and the ~340mb is the memory usage after the benchmark
> completes and the connection and everything else has been closed.
> ~340mb is
> still being held on to. It is not a matter of this being acceptable for
> our
> benchmark. That has run and served it’s purpose now. The larger
> question is
> the implication for a lived deployed system if we use the provider. I
> have
> found no way of getting the 340mb of memory to free up again without
> terminating the process. This might be fine for this little benchmark
> or
> even for a one off migration. The problem comes when using  the FDO
> provider
> with MapGuide enterprise. If the provider does have a memory leak then
> the
> consequence is that memory will be leaked whenever any data is
> retrieved
> though FDO from SDF. On a busy web server the effect of this is that
> eventually the web server will run out of memory and crash. The memory
> is
> only freed up by terminating the process which in this case would mean
> taking down the web server and starting it up again.
>
> The mapguide work being carried out is for a high profile organisation
> and a
> very important client of ours.
> It is part of a mission critical application which is being migrated
> from
> legacy map guide 6 to map guide enterprise. You can imagine then the
> prospect of a potential memory leak which could theoretically crash a
> web
> server is a bit worrying to say the least.
>
> It is not the case that I would be unwilling to admit that there were a
> problem with my code if I really believe that were the case. Right now
> the
> most important thing is just establishing what the cause of the problem
> is.
> This benchmark in itself is just a very small part of a much bigger and
> far
> more important project. If this problem is exhibited with the benchmark
> is
> more worrying not in how it affects this individual program but the
> wider
> implications of it for the whole project.
>
> For that reason it has been suggested that my my colleague when he gets
> back
> on Tuesday and circumstances permitting is going to look into the
> source
> code C++ implementation of the SDF provider. He is our most experienced
> and
> capable developer. I for my part have a lot of work to complete
> relating to
> the migration and will only be able to look into this memory leak
> problem as
> circumstances permit.
>
> I will have to leave this issue for now to work on other things but
> will get
> back to you when I have something new to report.
>
> Regards
>
> Carl
>
> --
> View this message in context: http://www.nabble.com/RE%3A-SDF-3.0-
> Memory-Leak-tp18531236p18532184.html
> Sent from the FDO Internals mailing list archive at Nabble.com.
>
> _______________________________________________
> fdo-internals mailing list
> fdo-internals at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/fdo-internals