That's an awesome bug report... thx for all the hard work Jesse.
P.S. I thought you were supposed to be on vacation!
Jesse Kuhnert wrote:
Short version:
Some users have brought up what appears to be a genuine memory
consumption bug in the new OGNL expression compiling integration with
Tapestry. The good news is that we think(hope) it has now been
addressed and fixed and would urge anyone experiencing any abnormally
high memory usage of their Tapestry apps based around version 4.1.2 or
greater to give the latest 4.1.3-SNAPSHOT version a try.
Longer version:
This issue doesn't have anything to do with OGNL itself, just my
implementation of the new compiler api it provides within Tapestry.
The core reason for the high memory consumption is based around the
javassist class pool that is used when generating and compiling
"anything" in Tapestry - which also includes these new compiled OGNL
expressions.
The bug itself had to do with me generating javassist classes
needlessly on expressions that weren't compilable ~yet~. This is
also probably why only a few people have seen this issue while others
have been chugging along just fine.
The yet part comes in when you are dealing with an expression where
all object types involved in the expression can't be known yet. For
example, suppose you had a state object looking something like this:
public class UserState implements Serializable {
User _user;
public User getUser()
{
return _user;
}
public void setUser(User user)
{
_user = user;
}
}
public class User implements Serializable {
String _name;
public String getName()
{
return _name;
}
}
and you needed to display the user name which you check in an ognl
expression doing something like this:
Hello, <span jwcid="@Insert" value="ognl:state.user != null ?
state.user.name : 'unknown'" />
If the user object isn't null when this expression is compiled then
all is well and everything works great. If the user object ~is~ null
however, the expression can't be compiled to native code yet because
we have to do a lot of introspection and class hierarchy walking to
determine the best classes to cast to in the generated java code.
Tapestry falls back to using normal ognl evaluation in these instances
~until~ the user object isn't null - continually trying to compile and
checking for this condition until it succeeds. (there are instances
where it gives up forever as well)
The core bug was that I was interacting with javassist and setting up
the new generated compiled expression classes ~before~ doing the work
necessary to know whether or not the statement was compilable - so for
every check a new javassist class was needlessly created and cached
internally by javassist.
In development mode this isn't much of an issue as we can clear out
this cache of classes as often as we like - but in production we have
to leave the cache in tact as it can never really be known that
~every~ component / page in the system has definitely been loaded and
will never need to be referenced in another compiled statement again.
I think I fixed the bug by doing a JIT sort of javassist class
generation only after the majority of logic has passed that would
normally result in Tapestry knowing whether or not any particular
expression is compilable at all.
Post Summary:
Sorry to all for any worries/extra work this bug may have caused.
I'm obviously very interested in hearing what peoples results are when
using the new version. Now that I've put things along the right path
I'm sure that any remaining issues can be relatively quickly addressed
and fixed once reported.
--
Andreas Andreou - [EMAIL PROTECTED] - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
