Now that's an OGNL compiler error. Have you tried with OGNL
2.7.1-SNAPSHOT(just use the latest). OGNL
2.7 that comes with Tap 4.1.2 by default is known to have bugs with the
compiled expressions. Please try with the latest OGNL; it might just do the
trick.
Kalle
On 8/28/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote:
>
>
> 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]
>
>
