Well, there are probably a few things: -) If the issue belongs anywhere it is probably in the Tapestry jira. -) While I can see ognl errors about missing classes I have no idea what led up to these errors. For all I know you got a java.lang.OutOfMemory exception in your app and this is the fallout from that. What caused the out of memory error is what I need to know.
For me to fix it I have to see it - either with a re-producable bug report that somehow states what should vs. is happening or a yourkit snapshot profile of the apps memory - preferrably an object generation snapshot to show me the baseline vs. incremental changes. On 9/12/07, Peter Stavrinides <[EMAIL PROTECTED]> wrote: > What further information do you require over and above the bug report I > filed? > http://jira.opensymphony.com/browse/OGNL-120 > > Jesse Kuhnert wrote: > > 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] > >> > >> > > > > > > > > > --------------------------------------------------------------------- > 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]
