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
