> my configuration is as follows: > > JDK 6.01 32bit JVM (I have also tested on a 64 bit with no > luck) Tomcat 5.5.20 Debian Linux (2.6.15.28 kernel) Tapestry > 4.1.2-SNAPSHOT with ognl 2.7 >
Hi Peter, 4.1.2-SNAPSHOT is a typo, I suppose? > regards, > Peter > > Jesse Kuhnert wrote: > > I'd downgrade then if I were you. Extensive profiling with yourkit > > hasn't shed any new light on whatever problems others are having. > > The OGNL classes indeed aren't being kept in the javassist > pool from > > what I can tell. > > > > I have another yourkit snapshot binary to look at so we'll > see what that says. > > > > I don't remember - have you filed any bug reports or reported any > > problems? Are you getting ognl exceptions during > development as well > > as production? Do these errors sound like > ummmmm....potential errors > > that should be looked at further? > > > > On 8/28/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote: > > > >> Hi Jessie > >> > >> Any progress on this? .... sorry to bug you, but I have to take a > >> decision soon, I have two production machines that will need to > >> upgrade or downgrade Tapestry. > >> > >> Best wishes, > >> Peter > >> > >> Jon Oakes wrote: > >> > >>> Hi Bryan, > >>> > >>> I am a relative newbie but I was wondering if you are > running with > >>> caching enabled or disabled? It might make sense to keep things > >>> around when caching is disabled whereas I think it would > clearly be > >>> a bug to keep things around with it disabled. > >>> > >>> Jon Oakes > >>> > >>> > >>> Jesse Kuhnert wrote: > >>> > >>>> Hmmm...well, I don't think I like the sound of any of > that. I'm just > >>>> going to pretend this problem doesn't exist. (just kidding) > >>>> > >>>> I had thought I was doing something special with the ognl > >>>> compilations that would cause its generated classes to not hang > >>>> around afterwards in any pools. > >>>> > >>>> I'll take a look at things this weekend and am sure a fix will > >>>> appear in between now and Monday - if there is a > reasonable fix to be found. > >>>> (in 4.1.3 snapshot form) > >>>> > >>>> On 8/24/07, Bryan Dotzour <[EMAIL PROTECTED]> > <mailto:[EMAIL PROTECTED]> wrote: > >>>> > >>>> > >>>>> I and another colleague of mine have been investigating > what seems > >>>>> to be a "memory leak" in our Tapestry application for about a > >>>>> month since we upgraded to T4.1.2. I won't bore you > with the saga > >>>>> of the last month, but I would like to present the data I've > >>>>> gathered and look to the list for a proposed solution. I was > >>>>> reading a recent thread in which Jesse said (08/09/2007): > >>>>> > >>>>> > >>>>> > >>>>> "There is a map that grows as large as the system using it > >>>>> internally to javassist of various cached reflection > info - but it > >>>>> doesn't leak in any way." > >>>>> > >>>>> This is precisely what I've found in profiling our > application and > >>>>> it > >>>>> *appears* to be this map that is causing our applications to > >>>>> eventually run out of memory. > >>>>> > >>>>> The YourKit profiler shows me that, as time goes on, > there is an > >>>>> instance of HiveMindClassPool that grows and grows as class > >>>>> instances are created. This class extends from > >>>>> javassist.ClassPool and is the map that Jesse is > talking about in > >>>>> his quote above. And he's right, I wouldn't say that the class > >>>>> pool "leaks" either because it looks like it's designed > to retain > >>>>> that memory until the class pool itself is no longer needed. > >>>>> > >>>>> > >>>>> > >>>>> Take this quote from the javassist.ClassPool javadocs: > >>>>> > >>>>> "Memory consumption memo: > >>>>> ClassPool objects hold all the CtClasses that have been > created so > >>>>> that the consistency among modified classes can be guaranteed. > >>>>> Thus if a large number of CtClasses are processed, the > ClassPool > >>>>> will consume a huge amount of memory. To avoid this, a > ClassPool > >>>>> object should be recreated, for example, every hundred classes > >>>>> processed. Note that > >>>>> getDefault() is a singleton factory. Otherwise, detach() in > >>>>> CtClass should be used to avoid huge memory consumption. " > >>>>> > >>>>> This huge memory consumption by the ClassPool is what I was > >>>>> seeing. In particular it is the ClassPool that is held > onto by OgnlRuntime. > >>>>> Inspecting this object in the profiler showed that it has a map > >>>>> containing about 45,000 classes. All of the keys into this map > >>>>> were things like: "ASTTest_11494aca9af" and > "ASTAnd_11494ace4fb" > >>>>> and the values are instances of javassist.CtNewClass. > Each entry > >>>>> in this map looks like it retains about 1,900 bytes, > for a grand > >>>>> total of about 90 MB of memory used. > >>>>> > >>>>> These numbers came from my staging deployment where I had the > >>>>> profiler attached, using some reflection tricks I was > able to look > >>>>> at a production site and found that it had about > 240,000 items in > >>>>> that class pool.. approximately 450 MB of memory. > >>>>> > >>>>> So I guess the questions in my mind are: Why are there so many > >>>>> classes in the pool? Why does the number only ever go up? Do > >>>>> those classes really need to stay in the pool forever? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > -------------------------------------------------------------------- > >>> - 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
