[fdo-internals] SDF 3.0 Memory Leak

[Carl Jokl]

I just did a test using the PostGIS provider. I am not able to compare like
for like data today but could likely do so on Monday. I would need to
convert the test data file to shape and import it to PostGIS. This requires
a tool and a colleague with access to it who has gone home for the weekend. 

I did test with the existing smaller data file which was imported from a
~92mb shape file into PostGIS. The same spiralling memory was observed with
the end result being that the memory usage after the end was about ~121mb of
ram which is a similar ratio as observed with SDF. It looks then like it
could be a problem spanning multiple providers.

One change I would like to make to the code to try and observe the
difference is that when loading data from a source to keep the test code
flexible and not bound to a specific source the individual FDO Entry class
uses the MgClassDefinition object and it's contained property definition
collection to figure out what the contained properties are and what data
type they have and retrieves the values automatically. This is happening on
a per entry basis and the class definition does not get disposed nor the
property collection. The problem is that if I do dispose of these after
reading an item then this makes them unavailable in the reader for
subsiquent calls. The solution is to read the feature reader metadata once
and store the values in my own managed objects which will be garbage
collected. These managed objects will then be used to decide what needs to
be loaded out of the feature reader and will be garbage collected once they
are no longer needed. The ClassDefiniton and corresponding property
collection can then be safely disposed of.

I have to go now because the building is being locked up.

-- 
View this message in context: http://www.nabble.com/RE%3A-SDF-3.0-Memory-Leak-tp18531236p18533302.html
Sent from the FDO Internals mailing list archive at Nabble.com.