[fdo-internals] SDF 3.0 Memory Leak

Robert Fortin robert.fortin at autodesk.com
Fri Jul 18 12:53:11 EDT 2008


"It looks then like it could be a problem spanning multiple providers."

As Traian said:
"The problem you are seeing is some interplay of the managed wrappers to FDO and your test code."

This wouldn't be provider specific.  It is likely to show up with any provider that you will test.

Robert

-----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 12:44 PM
To: fdo-internals at lists.osgeo.org
Subject: RE: [fdo-internals] SDF 3.0 Memory Leak


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.

_______________________________________________
fdo-internals mailing list
fdo-internals at lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/fdo-internals


More information about the fdo-internals mailing list