The problem continues... I will file a bug report.
Peter Stavrinides wrote:
Okay, I will try and build with this version... lets see if it makes a
difference.
Holger Stolzenberg wrote:
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]
---------------------------------------------------------------------
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]
