No Marcus
[EMAIL PROTECTED] wrote:
So changing the page pool parameters didn't help then?
-----Original Message-----
From: Peter Stavrinides [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 28, 2007 10:34 AM
To: Tapestry users
Subject: Re: Memory consumption in T4.1.2 - Hard data
Andreas, give me a break! I am not trying to trash Tapestry
if that's what you are thinking. I am not the only one
experiencing these problems.
Have a look at some of my postings (and others posts) and you
will see what I am talking about. I have been having these
problems since upgrading from 4.1.1 I never experienced these
problems before with uptime of months at a time.
Look at this log, id is an integer with the value 728:
21 Aug 2007 13:01:49,353 - INFO $Portfolio_89 - Setting the
portfolio with the id: 728
21 Aug 2007 13:01:50,479 - ERROR $Error_118 - Unable to parse
OGNL expression 'id': Unable to parse OGNL expression 'id':
Unable to parse OGNL expression 'id': ............
Exception [classpath:/org/apache/tapestry/form/TextArea.jwc,
line 49, column 67]
at
org.apache.tapestry.binding.ExpressionBinding.resolveExpressio
n(ExpressionBinding.java:145)
at
org.apache.tapestry.binding.ExpressionBinding.getObject(Expres
sionBinding.java:125)
And then take a look at this:
21 Aug 2007 07:56:50,613 - ERROR
org.apache.tapestry.services.impl.HiveMindExpressionCompiler
- Error generating OGNL getter for expression exceptions with
root [EMAIL PROTECTED]:Exception] and body:
{ return (($Exception_119)$2).getExceptions();}
org.apache.hivemind.ApplicationRuntimeException: Unable to
add method java.lang.Object get(ognl.OgnlContext,
java.lang.Object) to class $ASTProperty_1146a471a52: [source
error] no such class: $Exception_119
This happening after 3-4 days of normal operation? Suddenly
exceptions occur on random objects because OGNL can no longer
compile them and this is because Tapestry can no longer find
instances of these classes, it relates to JavaAssist dynamic
class loading. Also, currently the server is idle with no
connections and JConsole shows 18000 classes loaded,
yesterday there were 7000 classes, this number never goes
down only up, so you tell me what's going on?
If Jessie can't explain it, then I have to go back a version
we cant afford for clients to see broken pages, my boss
doesn't care about the problem, he just wants a solution and
its my job and reputation is at stake.
Andreas Andreou wrote:
Peter,
though not officially final (I believe), http://news247.gr
(tap-4.1.2)
has been getting 400000 req/day for an uptime of 26 days
with memory
set to no more than 128MB.
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]
