[fdo-internals] SDF 3.0 Memory Leak

[Carl Jokl]

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.