But that POM does use snapshots. You shouldn't need the repository http://people.apache.org/repo/m2-snapshot-repository at all. Probably, there are no very significant differences between the latest 4.1.2 snapshot and the release. But nevertheless, for a productive environment, I'd always go with a released version.
> -----Original Message----- > From: Peter Stavrinides [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 29, 2007 7:45 AM > To: Tapestry users > Subject: Re: Memory consumption in T4.1.2 - Hard data > > This is my POM: > > <repositories> > <repository> > <releases> > <updatePolicy>always</updatePolicy> > <checksumPolicy>warn</checksumPolicy> > </releases> > <snapshots> > <updatePolicy>always</updatePolicy> > <checksumPolicy>fail</checksumPolicy> > <repository> > <id>apache.snapshots</id> > <url>http://people.apache.org/repo/m2-snapshot-repository</url> > </repository> > </repositories> > > <dependency> > <groupId>org.apache.tapestry</groupId> > <artifactId>tapestry-framework</artifactId> > <version>4.1.2-SNAPSHOT</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.apache.tapestry</groupId> > <artifactId>tapestry-annotations</artifactId> > <version>4.1.2-SNAPSHOT</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.apache.tapestry</groupId> > <artifactId>tapestry-contrib</artifactId> > <version>4.1.2-SNAPSHOT</version> > <scope>test</scope> > </dependency> > <dependency> > <groupId>org.apache.tapestry</groupId> > <artifactId>tapestry-portlet</artifactId> > <version>4.1.2-SNAPSHOT</version> > <scope>test</scope> > </dependency> > > [EMAIL PROTECTED] wrote: > > > > > >> 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] > > > > > > > --------------------------------------------------------------------- > 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]
