Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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, > >> > >> 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 > >> no
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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, 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]
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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, > > 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
RE: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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, 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]
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Thanks for the quick fix, will give it a try! Peter Renat Zubairov wrote: Thanks Jesse! Solution of this bug was a clear sign for us to switch to the latests Tapestry version. Would be very nice to have a new release ASAP that we can use it in production. Renat On 07/09/2007, Jesse Kuhnert <[EMAIL PROTECTED]> 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, 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]
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Thanks Jesse! Solution of this bug was a clear sign for us to switch to the latests Tapestry version. Would be very nice to have a new release ASAP that we can use it in production. Renat On 07/09/2007, Jesse Kuhnert <[EMAIL PROTECTED]> 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, > > 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] > > -- Best regards, Renat Zubairov - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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, 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]