[Geotools-devel] Allowing web applications to undeploy without perm gen leaks, a first cut

[Andrea A. <aa...@op...>]

Hi,
so as you I've been working on allowing web applications to properly 
undeploy without leaking permanent generation memory. I have a first
cut that solves all the problems I've been able to find so far.

Unfortunately it still does not allow GS to actually undeploy cleanly,
but it's a step in the right direction and makes debugging whatever
else is missing easier.

The set of issues I've been looking into is detailed in this
page:
http://wiki.apache.org/tomcat/MemoryLeakProtection

Basically our referencing/coverage subsystems violated every rule in
that page, and I guess more, since GS still does not deploys cleanly
and I'm at a loss at finding more reasons for that ;-)

Anyways, the attached patch contains changes that either handle
the issue or make it easier to look for further problems.
In particular:
- cleans up all the thread locals I could actually get rid of
- it exposes a CRS.cleaupThreadLocals() for the two thread locals
   that I could not get rid of and that cannot be easily removed
   either. A web application must add a filter that calls that
   method after each request (annoying, I know)
- adds methods to empty all SPI registries before shutdown
- changes CRS2GeoTiffMetadataAdapter to use the factories exposed
   by the referencing subsystem instead of creating its own
   transform factory (which in turn holds another SPI registry).
   Don't worry for this one, the transform factory returned
   by the finder is cached itself, so it's really just removing
   a duplication
- removes the ThreadedEPSGFactory shutdown hook, a thread
   that is registered globally in the JVM for the purpose of
   shutting down the EPSG database connections... something
   that is completely not needed, as the connections simple cease
   existing and the embedded databases are all working read only
   (so they can be killed abruptly without issues)

As for adding a method in GeoTools that makes all the necessary
calls to shut down the application, it can get tricky due
to dependencies (it should be in a central module, but from
that central module you don't see all the necessary dependencies).
So what about a page explaining what one should do instead?
Is there a place in the sphinx docs for that?

I plan to commit the changes tomorrow on trunk only
unless someone objects

Cheers
Andrea

-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.