[Resin-interest] Slow Alarm?
I think there was some stuff about this before, but what is the Slow Alarm
warning in the logs? I see a lot of this after my resin instance has been
running on my MacBook Pro (Lion) for a day or more. I often close the lid to
sleep it while I transport it.
I get entries like this:
[12-04-24 11:34:23.226] {CoordinatorThread[]-2} AlarmClock slow alarm
Alarm[alarm[NetworkListenSystem[]]] 1650229ms coordinator-delta 1679714ms
[12-04-24 11:34:23.226] {CoordinatorThread[]-2} AlarmClock slow alarm
Alarm[alarm[ConnectionPool[jdbc/satdb]]] 1649693ms coordinator-delta 1679714ms
[12-04-24 11:34:23.226] {CoordinatorThread[]-2} AlarmClock slow alarm
Alarm[alarm[com.caucho.log.AbstractRolloverLog$RolloverAlarm@74e427ed]]
1157409ms coordinator-delta 1679714ms
--
Rick
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Out of PermGen space
When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
On 24.04.2012 22:54, Rick Mann wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? Nope. The standard setting is pretty low. I usually set MaxPermSize to 256M. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
On Apr 24, 2012, at 14:32 , Olaf Krische wrote: On 24.04.2012 22:54, Rick Mann wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? Nope. The standard setting is pretty low. I usually set MaxPermSize to 256M. Mine is set higher. It runs fine for some time. Eventually, it'll try to reload the app, and get this error. Memory in my app (or in Resin) is leaking, and I don't know why (nor enough about java debugging to figure out where the leak is). -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
Well, yes and no. As I understand the problem, it really got bad around the Java 5 timeframe because of the addition of Enumerations to the language. What Resin does (and all auto-reloading Java containers do) is to create a ClassLoader that contains all the code for your application. When it senses a change to your code, it loads that new code into a brand new ClassLoader and releases the old one to be garbage collected once it's done processing it's active requests. The problem is that, since Enumerations are guaranteed to work with the == operator, even when serialized/deserialized between different computers, Java treats them special, by keeping them in the Permanent Generation (so their internal ID's won't change). Unfortunately, each time the app is loaded a new set of Enumerations takes up more space in the precious PermGen until it finally blows its lid. So, theoretically, you could use less PermGen by limiting Enumeration use, but that's really not a realistic response. Before Java became property of Oracle, there was some talk about fixing this problem at the JVM level, but I haven't heard anything in quite a while. (*Chris*) On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann rm...@latencyzero.com wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
Out of PermGen space is almost always caused by a classloader leak which occurs when a webapp is reloaded. It could be caused by either your own code, third-party code, or in some case Java core classes. You need to take heap dumps before and after webapp reload and use a heap analyzer to see what is holding onto the leaked classloader(s). Bill On Tue, Apr 24, 2012 at 5:41 PM, Chris Pratt thechrispr...@gmail.comwrote: Well, yes and no. As I understand the problem, it really got bad around the Java 5 timeframe because of the addition of Enumerations to the language. What Resin does (and all auto-reloading Java containers do) is to create a ClassLoader that contains all the code for your application. When it senses a change to your code, it loads that new code into a brand new ClassLoader and releases the old one to be garbage collected once it's done processing it's active requests. The problem is that, since Enumerations are guaranteed to work with the == operator, even when serialized/deserialized between different computers, Java treats them special, by keeping them in the Permanent Generation (so their internal ID's won't change). Unfortunately, each time the app is loaded a new set of Enumerations takes up more space in the precious PermGen until it finally blows its lid. So, theoretically, you could use less PermGen by limiting Enumeration use, but that's really not a realistic response. Before Java became property of Oracle, there was some talk about fixing this problem at the JVM level, but I haven't heard anything in quite a while. (*Chris*) On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann rm...@latencyzero.com wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin Pro 4.0.24 w/Quercus trying to get MediaWiki 1.18.2 to work..
Howard Leadmon schrieb am 23.04.2012 um 19:27 (-0400): At that point it put up a nice red stop symbol, and gave the following error: Your session data was lost! Check your php.ini and make sure session.save_path is set to an appropriate directory. Check the php-ini config section here: http://www.mail-archive.com/resin-interest@caucho.com/msg00602.html Might help. Haven't tried it. Is there any solution to this, and if so my google fu is failing me today, as I can't seem to find it. All I did was: http://www.google.com/search?q=quercus+session.save_path -- Michael Ludwig ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
Hello Chris, this actually makes me wonder: are enums eating so much space, especially when compared to those things, that you release with the classloader? Heard about this for the first time. Interesting. On 24.04.2012 23:41, Chris Pratt wrote: that, since Enumerations are guaranteed to work with the == operator, even when serialized/deserialized between different computers, Java treats them special, by keeping them in the Permanent Generation (so their internal ID's won't change). Unfortunately, each time the app is loaded a new set of Enumerations takes up more space in the precious PermGen until it finally blows its lid. So, theoretically, you could use less PermGen by limiting Enumeration use, but that's really not a realisticOn ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Out of PermGen space
On 04/24/2012 03:13 PM, Bill Au wrote: Out of PermGen space is almost always caused by a classloader leak which occurs when a webapp is reloaded. It could be caused by either your own code, third-party code, or in some case Java core classes. You need to take heap dumps before and after webapp reload and use a heap analyzer to see what is holding onto the leaked classloader(s). As a quick check, if you're using Resin 4.0 Pro, the PDF dump shows ZombieClassLoaderMarker in the heap dump section. Or you can use a heap analyzer and look for ZombieClassLoaderMarker and do a search-to-root on it. In Resin, a zombie classloader is one that Resin expects to be garbage collected. -- Scott Bill On Tue, Apr 24, 2012 at 5:41 PM, Chris Pratt thechrispr...@gmail.com mailto:thechrispr...@gmail.com wrote: Well, yes and no. As I understand the problem, it really got bad around the Java 5 timeframe because of the addition of Enumerations to the language. What Resin does (and all auto-reloading Java containers do) is to create a ClassLoader that contains all the code for your application. When it senses a change to your code, it loads that new code into a brand new ClassLoader and releases the old one to be garbage collected once it's done processing it's active requests. The problem is that, since Enumerations are guaranteed to work with the == operator, even when serialized/deserialized between different computers, Java treats them special, by keeping them in the Permanent Generation (so their internal ID's won't change). Unfortunately, each time the app is loaded a new set of Enumerations takes up more space in the precious PermGen until it finally blows its lid. So, theoretically, you could use less PermGen by limiting Enumeration use, but that's really not a realistic response. Before Java became property of Oracle, there was some talk about fixing this problem at the JVM level, but I haven't heard anything in quite a while. (*Chris*) On Tue, Apr 24, 2012 at 1:54 PM, Rick Mann rm...@latencyzero.com mailto:rm...@latencyzero.com wrote: When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com mailto:resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Out of PermGen space
Hi Rick. After having had these issues for years, I started blogging about it and how to find classloader leaks [1]. I also compiled a list of API calls and third party libraries known to trigger these leaks [2], and as you can see, it is quite common both to cause these problems yourself and to have them caused by some dependency. Having done the research, I ended up creating a small library that you can add to you web application, that will clean up strong references keeping your classloader from being garbage collected [3]. Somewhat like Tomcat has built in, but taking care of more of the known problems. I suggest you add this library to you app and watch the logs (feel free to report your findings). Having said that, I should admit that I'm still seeing PermGen crashes running under Resin, even when there are no visible strong references to my classloader. I have not had time to investigate whether this is caused by Resin (such as the HotSwap capability), or if it is some JVM bug (and possibly something with IntelliJ, as the problem increases using the IntelliJ Resin plugin). I should probably try turning HotSwap off, or try another application server - or another JVM. Someday... Good luck! /Mattias 1: http://java.jiderhamn.se/2011/12/11/classloader-leaks-i-how-to-find-classloader-leaks-with-eclipse-memory-analyser-mat/ 2: http://java.jiderhamn.se/2012/02/26/classloader-leaks-v-common-mistakes-and-known-offenders/ 3: http://java.jiderhamn.se/2012/03/04/classloader-leaks-vi-this-means-war-leak-prevention-library/ - Original Message - Subject: [Resin-interest] Out of PermGen space Date: Tue, 24 Apr 2012 13:54:40 -0700 From: Rick Mann rm...@latencyzero.com When I'm making changes to the code of a webapp, Resin kindly reloads it for me. I can usually get a handful of reloads in before Resin complains about being out of PermGen space. Is there something I'm doing wrong in my app that it leaks like this? -- Rick ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
