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
