Isn't the major source of the OP's memory use though the 600+ new
instances of javassist.CtNewClass in the classes hashmap per page load? Are
you thinking that a simple page with two property selects on it ought to
require 600+ support classes to back it, because that sounds about two
orders of magnitude too high to me.
Are you sure there's not some sort of underlying bug in javassist
and/or Howards implementation thereof?
--- Pat
> -----Original Message-----
> From: Hensley, Richard [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 06, 2005 10:24 AM
> To: Tapestry users
> Subject: RE: OutOfMemoryError Tapestry 4.0
>
> Generated Classes are loaded into a class loader so they can be
> instantiated
> by Tapestry and Hivemind. The only way to release the generated classes is
> to release the class loader.
>
> I tried once to evict classes from a ClassLoader while I was doing some
> Groovy stuff, according to the ClassLoader specification, it's not
> possible
> to evict a class. After you think about it for a while, you come to the
> conclusion that this is a good thing.
>
> I think that Hivemind and Tapestry load the generated classes into the
> same
> class loader that owns the parent class of the generated class. This class
> loader can not be released because it is owned by the application
> container.
> So, the real question is why are some many classes being generated. The
> flag
> noted by Howard below causes a class to be generated each time a page with
> abstract properties is visited. When running in production, my experience
> is
> that the classes only get generated the first time they are needed.
>
> So, the next avenue of investigation is to figure out what the actual
> generated classes are that were being reported as part of CtClass by the
> memory leak tool.
>
> Richard
>
> -----Original Message-----
> From: Leonardo Quijano Vincenzi [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 06, 2005 10:10 AM
> To: Tapestry users
> Subject: Re: OutOfMemoryError Tapestry 4.0
>
> Howard Lewis Ship escribió:
>
> >That might be reasonable if you are running with
> >-Dorg.apache.tapestry.disable-caching=true
> >
> >With caching disabled, Tapestry has to constantly create new enhanced
> >subclasses for every page and every component.
> >
> >
> Shouldn't it delete old classes?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
