We looked into the problem for a bit - GMLComplexType has a AbstractFeatureCollectionType which pays attention to a Streaming hint as set by FCBuffer.run().
Somehow we need to pay attention to this hint and clean up the list (the elements LinkedList) from the ComplexElementHandler assigned to the AbstractFeatureCollection. Fun. Tim implemented a bit of hack, added a removeElement method to ComplexElementHandler so he could call it from the SAX parser, we refined it a bit so it would only remove the handler when we were working on parsing feature for an AbstractFeatureCollectionType ... This is a temporary fix so we can see if any other memory leaks exist - we need to figure out the right way to do this sort of thing. We may end up making a special CompleElementHandler to use when the Streaming hint is thrown. We would need to ensure that it is *only* invoked when working on the FeatureType, this information has been set as the DEBUG_INFO_FEATURE_TYPE_NAME hint byt FCBuffer.initHints method. Tim is going to do a bit of an experiment and report back, Jody Tim Englich wrote: > Hello Jody, > > the changes do not have the effect we expected. > > Now we found another part that causes the memory Leak. > The class org.geotools.xml.handlers.ComplexElementHandler contains a list. > For one instance of this Class (I think the instance for the parent element > of the features) the list is as big as the number of features read from the > InputStream. > I think we have to remove this elements when they are handled. > > Let's talk about it on IRC. > > Tim > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Geotools-gt2-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users
