[geotk] Out of memory error when decoding CRS
Brian Schlining
bschlining at gmail.com
Wed May 25 12:05:14 EDT 2011
Here's some info about setting permgen space ...http://stackoverflow.com/questions/3003855/increase-permgen-space
--
Brian Schlining
On Wednesday, May 25, 2011 at 3:52 AM, Jon Blower wrote:
> Hi,
>
> Sorry to join this late – I notice that this is a PermGen memory error, which is connected with classloading, not heap memory usage. This commonly happens when redeploying a web application without a clean restart of the app server. I don’t fully understand this type of error, but you might like to try cleanly restarting your app server (if you’re using one) or increasing the permgen space using a command-line switch to the JVM (sorry, can’t remember what the syntax is!)
>
> HTH,
> Jon
>
> From: geotoolkit-bounces at lists.osgeo.org [mailto:geotoolkit-bounces at lists.osgeo.org] On Behalf Of Riou Olivier
> Sent: 25 May 2011 05:47
> To: 'Martin Desruisseaux'; geotoolkit at lists.osgeo.org; Riou Olivier
> Subject: RE: [geotk] Out of memory error when decoding CRS
>
> Hi Martin,
>
>
>
> I have no log file but I see in the service.properties that it use the derby database.
>
> The CRS I try to instantiate are WGS84 (epsg code 4326), WGS72 (epsg code 4322), ED1950 (epsg code 4230), OSGB36 (epsg code 4277), OSSN80 (epsg code 4279) and all UTM (epsg codes starting at 32600 and 32700) (epsg.properties in attachment).
>
>
>
> The CRS transform I'm currently developping is integrated in real-time SIG application based on Worldwind and which uses many services such communication, database ... So it may use a lot of memory, I think I'm going to profile the application because I saw that geotoolkit does not use so much memory.
>
>
>
> I also have a mistake in my code because I was expecting that geotoolkit was loading only my epsg.properties file but since I use the CRS.decode(...) function, it also initialize the embedded database. When I remove the call to this method and load a CRS through the PropertyEpsgFactory it does not initialize the embedded database and use less memory.
>
>
>
> Olivier
>
>
>
> > -----Message d'origine-----
> > De : Martin Desruisseaux [mailto:martin.desruisseaux at geomatys.fr]
> > Envoyé : mardi 24 mai 2011 15:26
> > À : geotoolkit at lists.osgeo.org; Olivier.Riou at fr.thalesgroup.com
> > Objet : Re: [geotk] Out of memory error when decoding CRS
> > Hello Olivier
> >
> > I just made a try, and I have been able to instantiate EPSG:27572 ("NTF (Paris) / Lambert zone II") with only 32 Mb (java -Xmx32M) using the Derby (a.k.a. JavaDB) database. In order to investigate more, the following information would be useful:
> > Which EPSG code are you instantiating?
> > Which database are you using? You can find this information from the logs, which should contain a message like: "INFO [ThreadedEpsgFactory] Connecté à la base de données EPSG "jdbc:hsqldb:/Users/desruisseaux/Library/Geotoolkit.org/EPSG/HSQL/7.06" sur "HSQL Database Engine".".
> > Is there any other memory-consuming application running in same time.
> >
> >
> >
> > Le 24/05/11 14:55, Riou Olivier a écrit :
> > I've got the following error when decoding a CRS from my java application :
> >
> > java.lang.OutOfMemoryError: PermGen space
> > at java.lang.ClassLoader.defineClass1(Native Method)
> > (...snip...)
> > at java.lang.ClassLoader.loadClass(Unknown Source)
> > (...snip...)
> > at org.geotoolkit.referencing.factory.epsg.ThreadedEpsgFactory.createBackingStore(ThreadedEpsgFactory.java:636)
> >
> > According this stack trace, the OutOfMemoryError happen at class loading time. So its look like that the DirectEpsgFactory Geotk code has not been executed at all, since the class did not even had a chance to be loaded in the JVM. I think that something else consumed a huge amount of memory before to reach the point where Geotk create a CRS object from an EPSG code.
> >
> > Regards,
> >
> > Martin
> _______________________________________________
> Geotoolkit mailing list
> Geotoolkit at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geotoolkit
>
More information about the Geotoolkit
mailing list