T4.1.2 is released and in the main repo:
http://mvnrepository.com/artifact/org.apache.tapestry/tapestry-framework
My POM:
<dependency>
<groupId>org.apache.tapestry</groupId>
<artifactId>tapestry-framework</artifactId>
<version>4.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.tapestry</groupId>
<artifactId>tapestry-annotations</artifactId>
<version>4.1.2</version>
</dependency>
<dependency>
<groupId>org.apache.tapestry</groupId>
<artifactId>tapestry-contrib</artifactId>
<version>4.1.2</version>
</dependency>
<dependency>
<groupId>com.ewerk</groupId>
<artifactId>ewerk-tapestry-components</artifactId>
<version>0.0.7</version>
</dependency>
<dependency>
<groupId>com.javaforge.tapestry</groupId>
<artifactId>tapestry-spring</artifactId>
<version>1.0.0</version>
<!-- exclude the old referenced version of tapestry -->
<exclusions>
<exclusion>
<groupId>tapestry</groupId>
<artifactId>tapestry</artifactId>
</exclusion>
<exclusion>
<groupId>tapestry</groupId>
<artifactId>tapestry-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
Mit lieben Grüßen aus dem eWerk
| Holger Stolzenberg
| Softwareentwickler
|
| Geschäftsführer:
| Frank Richter, Erik Wende, Hendrik Schubert
|
| eWerk IT GmbH
| Markt 16
| Leipzig 04109
| http://www.ewerk.com
| HRB 9065, AG Leipzig
| Hauptniederlassung Leipzig
|
| fon +49.341.4 26 49-0
| fax +49.341.4 26 49-88
| mailto:[EMAIL PROTECTED]
|
| Support:
| fon 0700 CALLME24 (0700 22556324)
| fax 0700 CALLME24 (0700 22556324)
|
| Auskünfte und Angebote per Mail
| sind freibleibend und unverbindlich.
-----Ursprüngliche Nachricht-----
Von: Peter Stavrinides [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 29. August 2007 09:31
An: Tapestry users
Betreff: Re: Memory consumption in T4.1.2 - Hard data
Correct me if I am wrong 4.1.2 is not released as yet, and not in the main
repository, so how else would I get to it?
[EMAIL PROTECTED] wrote:
> 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]
>
>
---------------------------------------------------------------------
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]
