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
