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.resolveExpression(ExpressionBinding.java:145)
at
org.apache.tapestry.binding.ExpressionBinding.getObject(ExpressionBinding.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]
