You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Jesse Kuhnert <jk...@gmail.com> on 2007/09/07 19:34:37 UTC
[info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest
4.1.3-SNAPSHOT
Posted by andyhot <an...@di.uoa.gr>.
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 - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <p....@albourne.com> 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 <P....@albourne.com> 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: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >>
> >>
> >> .
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest
4.1.3-SNAPSHOT
Posted by Peter Stavrinides <p....@albourne.com>.
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 <P....@albourne.com> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>>
>>
>> .
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <P....@albourne.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> .
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Posted by Peter Stavrinides <P....@albourne.com>.
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
.
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest
4.1.3-SNAPSHOT
Posted by Peter Stavrinides <p....@albourne.com>.
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 <jk...@gmail.com> 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.
>>
>> --
>> 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: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [info] Tapestry >= 4.1.2 memory issues potentially fixed in latest 4.1.3-SNAPSHOT
Posted by Renat Zubairov <re...@gmail.com>.
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 <jk...@gmail.com> 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.
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Best regards,
Renat Zubairov
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org