Hi Jody, Hello Jody, I put my solution as an comment to the Ticket.
You say that there is a switch to use an other reader than StrictFeatureReader. How can I do that so that I can revoke my changes on StrictFeatureReader? Can I put the information into the Map used to create the Datastore? You are right that the place where I remove the wasted childs is not good. But I haven't found a better place do do this. You asked me to put together a patch. What does that mean to me? Should I send the manipulated Files to you? I have got some other changes to the DateTime an Date classes of the XML-Parsing. Could I also send it to you that you integrate it into the Project? - Tim -----Ursprüngliche Nachricht----- Von: Jody Garnett [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 15. Juni 2007 22:57 An: Tim Englich Cc: [email protected] Betreff: Re: AW: Updated ... Memory Leak in WFS-Plugin - GEOT-1298 Woot! - that is cool enough we should put it as a comment on GEOT-1298. Can you do the honours? We still should look at how to handle this one a bit better - only calling removeElement when the streaming hint is on. - XMLSAXHandler.endElement is this the only place we could arrange to removeElement? It seems to be at the wrong level of abstraction (having to check the class name in a different module for example) - Change to StrictFeatureReader - there should already be a switch we can throw to avoid the StrictFeatureReader (we have run into so many bad WFS servers that report back the same FID multiple times that this class is useful). So here is the question Tim - can you put together a patch to that effect (so we can fix the library?), or is is working with your forked code going to hold you ... Cheers, Jody > Hello Jody, > thanks for the help yesterday. > We now have fixed the leak(s). > > There were three changes I had to do. > > First one: > > I manipulated the Class org.geotools.xml.handlers.ComplexElementHandler. > There I added two new Methods. > > /** > * @param handler > */ > public void removeElement(XMLElementHandler handler){ > if (elements != null){ > elements.remove(handler); > } > } > > /** > * Liefert den Wert des Feldes: type > * @return type > */ > public ComplexType getType() { > return type; > } > > Second one: > > I manipulated the finally block of the > org.geotools.xml.XMLSAXHandler.endElement(String namespaceURI, String > localName, String qName) Method > > }finally{ > handlers.pop(); > if (handler != null && !handlers.isEmpty()){ > XMLElementHandler parent = > ((XMLElementHandler)handlers.peek()); > if (parent instanceof ComplexElementHandler){ > ComplexElementHandler complexParent = > (ComplexElementHandler)parent; > String typename = > complexParent.getType().getClass().getName(); > // TODO: HACK The required Type is not > available in this Module > > if(typename.equals("org.geotools.xml.wfs.WFSBasicComplexTypes$FeatureCollecti > onType")){ > complexParent.removeElement(handler); > } > } > } > } > > Only for parent Elements which Type is an instance of > org.geotools.xml.wfs.WFSBasicComplexTypes$FeatureCollectionType the child > element should be removed. > This prevent that the linked list will grows up. > The solution is not very nice but work. > > Third one: > > I removed the private Set foundFids=new HashSet(); Attribute of the Class > org.geotools.data.wfs.StrictWFSStrategy$StrictFeatureReader > The set holds every ID of an recieved feature. This was to big an grows very > fast. > It was used to validate the FeatureIDs that they were unique. This should > every WFS do on his own. > > Now we have no further increasing of Memory. > > Tim > > > > > -----Ursprüngliche Nachricht----- > Von: Jody Garnett [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 14. Juni 2007 22:05 > An: Tim Englich > Cc: [email protected] > Betreff: Updated ... Memory Leak in WFS-Plugin - GEOT-1298 > > > 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
