Re: [Geoserver-devel] memory leak - XSD classes

[Niels <nie...@cs...>]

> Not sure I follow. Those preventer adapters should now allow the same 
> element or schema to be added more than once... so I am curious as to 
> how the back references are accumulating. So while maybe right away 
> the objects won't be deferenced but eventually hey should be. Although 
> if you are building up multiple different schemas I can see how this 
> could be an issue.

Well, what I meant to say is that even if the preventers were working, 
it wouldn't be enough. Say for example that an app-schema test builds a 
schema for a "blahblah" namespace, the preventers wouldn't remove it 
until another "blahblah" schema is built. However, I want it to be gone 
at the end of the test, no matter what, there is no point in keeping it 
around forever. That's why I concluded I should follow the path of 
active disposal of schema's rather than just preventing duplicates.

>
>     The consequences for App-schema are big though. In the current
>     setup, you specify your schema's for each datastore (for each
>     mapping). So even in one single test, multiple versions of the
>     GSML schema are alive. All of them accumulate to multiple
>     references in the substitution groups of GML for the same
>     element.  It just does not make any possible sense to link
>     multiple versions of  the GSML schema to one single GML schema in
>     memory! Because of the backwards links and substitution groups it
>     becomes one big clutter.
>
> Right... but is that not the problem that the preventers "prevent" :). 
> I am curious as to why they are not working on this case.
>
>
>     My solution is to keep a registry that maps schema locations to
>     schema's and reuse schema's that have already been built.
>     Performance and memory improvement at the same time.
>
>     In that case, the only way there could still be cluttering in the
>     XSD schema's in memory, if for some reason someone is using the
>     same schema in different file locations, or different versions of
>     the same schema, in different datastores of the same instance of
>     app-schema. I don't see a way to avoid that.
>
>
> Another possible solution would be to create some sort of wrapper, or 
> a registry in which every time client code builds a schema they should 
> register it. And when the schema object is not required any longer 
> there is some dispose method called. When that occurs the schema 
> removes itself from any schemas that it imported or referenced via 
> substitution group.
>
>
>

I think what you are saying is basically what I am doing.


Regards
Niels