Hmmm... I think I'm going to need a lot more detailed information than
that. I'm sure something is broken but without knowing more it's not
something I'm going to look in to.
On 9/11/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote:
> Hi Jessie and co,
>
> I upgraded to the snapshot this morning at 6:00am GMT, deployed and tested. I
> ran JConsole to monitor classes the whole day.. This evening I just had it
> crash again 14 hours later. Doesn't appear to be fixed, I get the same errors.
>
> I can see from your example that there may be a way I can avoid these crashes
> by changing my code, the trouble is how do I test it?
>
> Peter
>
> 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.
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
> ---------------------------------------------------------------------
> 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]
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
