You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Tomas Jucius <en...@gmail.com> on 2005/06/17 16:11:04 UTC
HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Here what I have found.. I can't develop my project because of this..
Because it depends on this feature..
As we all know tapestry put all things into pool ant it retrieves it
when you request for page and etc...
My application sometimes need to reset this pool..
So I use reset service..
But after a lot of resets jvm memory becomes full, and I get
"java.lang.OutOfMemoryError"
So after each reset some object are not collected.. And some
references to objects are left.. I could't find where..
if in class AbstractEngine you comment these lines in clearCachedData method
_pageSource.reset();
_pool.clear();
when memory usage stops growing bet pool is not cleared:)..
So I suppose what pool is buggy or something else.. couldn't figure..
TO SEE THIS BUG DEPLOY NEW APPLICATION WITH THESE FILES:
-----------------------------HomePage.java-------------------------------
mport java.io.IOException;
import java.util.Map;
import org.apache.tapestry.IMarkupWriter;
import org.apache.tapestry.IRequestCycle;
import org.apache.tapestry.Tapestry;
import org.apache.tapestry.engine.IEngineService;
import org.apache.tapestry.html.BasePage;
import org.apache.tapestry.util.prop.PropertyFinder;
public class HomePage extends BasePage {
public void beginResponse(IMarkupWriter writer, IRequestCycle cycle) {
// TODO Auto-generated method stub
System.out.println("redirect " +
cycle.getEngine().isResetServiceEnabled() + " " +
(Runtime.getRuntime().totalMemory()) );
redirectToResetService(cycle);
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
super.beginResponse(writer, cycle);
}
public void redirectToResetService(IRequestCycle cycle) {
IEngineService resetService =
cycle.getEngine().getService(Tapestry.RESET_SERVICE);
try {
cycle.getRequestContext().redirect((resetService.getLink(cycle,
this, null).getURL()));
resetService = null;
}
catch (IOException e) {
e.printStackTrace();
}
}
}
------------------------------Home.page-----------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE page-specification PUBLIC
"-//Apache Software Foundation//Tapestry Specification 3.0//EN"
"http://jakarta.apache.org/tapestry/dtd/Tapestry_3_0.dtd">
<!-- generated by Spindle, http://spindle.sourceforge.net -->
<page-specification class="HomePage">
</page-specification>
---------------------------Home.html------------------------------
<html>
<head>
</head>
<body>
<div jwcid="@Insert" value="leak" />
</body>
</html>
OPEN YOUR APPLICATION WITH EXPLORER IT HAS NO REDIRECTION LIMIT..
AND YOU CAN SET MAX MEMORY PROPERTY TO: -Xmx3M
IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
this insert)..
So maybe of component specifications it is leaking?
Used profiler.. I didn't see growing any tapestry object only
java.util.* classes..
Appreciate all your notes...
Tomas Jucius
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Shawn Church <sh...@boxity.com>.
Tomas,
I can understand why you might want to reset a page, but it would be
helpful if you could provide more detailed information so we don't have
to guess at your implementation.
I have an app running on a test server where I have tried to duplicate
this problem, but so far I haven't been able to. I have a
moderately-complex page, including @Form, @Foreach, @Insert,
@Conditional, @Hidden, @base:If, @base:Else, @contrib:Table,
@DirectLink, @Block, and a couple of custom components, and I can reset
it frequently and repeatedly (100 or more times), but I am not seeing
any indication of a memory leak. I have added a "-verbose: gc" argument
to my JVM startup options (so I can log garbage collection activity),
but everything looks good to me.
Please try adding "-verbose: gc" to your startup options and report what
you see in your logs. Also, it might be helpful to know what Java
version and what servlet container you are using. It would also be
important to know what other Java packages you are using (JDBC driver,
etc.).
Shawn
Quoting Tomas Jucius <en...@gmail.com>:
> Imho I need to reload page templates....
>
> There is no other sollution...
>
>
>
> On 6/20/05, Geoff Longman <gl...@gmail.com> wrote:
> > Perhaps it is a bug but I don't see the reasoning for doing what
> you
> > are doing in the first place.
> >
> > Why are you trying to clean out the pool?
> >
> > Geoff
> >
> > On 6/20/05, Tomas Jucius <en...@gmail.com> wrote:
> > > The Java Language Specification allows for the unloading of
> classes..
> > > And it is done during garbage collection...
> > >
> > > So it is tapestry bug..
> > >
> > > On 6/20/05, Robert Zeigler <rdzeigle@u.arizona.edu > wrote:
> > > > Tomas Jucius wrote:
> > > > > Here what I have found.. I can't develop my project because
> of this..
> > > > > Because it depends on this feature..
> > > > >
> > > > > As we all know tapestry put all things into pool ant it
> retrieves it
> > > > > when you request for page and etc...
> > > > >
> > > > > My application sometimes need to reset this pool..
> > > >
> > > > ?? What for? Aside from the development cycle, I can't think of
> any
> > > > reason to reset the pool. It's generally considered a bad idea
> to have
> > > > the reset service enabled during deployment.
> > > >
> > > > >
> > > > > So I use reset service..
> > > > >
> > > > > But after a lot of resets jvm memory becomes full, and I get
> > > > > "java.lang.OutOfMemoryError"
> > > > > So after each reset some object are not collected.. And some
> > > > > references to objects are left.. I could't find where..
> > > >
> > > > I haven't looked into this in great detail, but I suspect that
> it's the
> > > > same issue as discussed earlier, dealing with an alleged memory
> leak
> > > > when the disable-caching vm property is set to true. The
> general idea:
> > > > tapestry creates enhanced versions of the the classes,
> generating
> > > > concrete accessors for you, etc. Each time you reset, new
> enhanced
> > > > classes must be generated. But the JVM caches the classes, so,
> > > > eventually, the jvm runs out of memory due to the cached class
> > > > definitions, rather than any caching that tapestry is doing.
> Check out
> > > > the recent thread on this subject with the disable-caching vm
> property
> > > > set to true; somebody there posted a set of jvm arguments that
> seems to
> > > > sidestep the problem.
> > > >
> > > > > IF THEREIS NO ANY COMPONENT in page when it is not leaking
> (so I put
> > > > > this insert)..
> > > > > So maybe of component specifications it is leaking?
> > > >
> > > > Nope... your page has no properties in need of enhancement, but
> the
> > > > insert component does. Taking the components out = a single
> class
> > > > definition; putting the component in means each reset generates
> a new
> > > > enhanced insert class.
> > > >
> > > > Robert
> > > >
> > > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
> > > >
> > > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> tapestry-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Tomas Jucius <en...@gmail.com>.
Imho I need to reload page templates....
There is no other sollution...
On 6/20/05, Geoff Longman <gl...@gmail.com> wrote:
> Perhaps it is a bug but I don't see the reasoning for doing what you
> are doing in the first place.
>
> Why are you trying to clean out the pool?
>
> Geoff
>
> On 6/20/05, Tomas Jucius <en...@gmail.com> wrote:
> > The Java Language Specification allows for the unloading of classes..
> > And it is done during garbage collection...
> >
> > So it is tapestry bug..
> >
> > On 6/20/05, Robert Zeigler <rdzeigle@u.arizona.edu > wrote:
> > > Tomas Jucius wrote:
> > > > Here what I have found.. I can't develop my project because of this..
> > > > Because it depends on this feature..
> > > >
> > > > As we all know tapestry put all things into pool ant it retrieves it
> > > > when you request for page and etc...
> > > >
> > > > My application sometimes need to reset this pool..
> > >
> > > ?? What for? Aside from the development cycle, I can't think of any
> > > reason to reset the pool. It's generally considered a bad idea to have
> > > the reset service enabled during deployment.
> > >
> > > >
> > > > So I use reset service..
> > > >
> > > > But after a lot of resets jvm memory becomes full, and I get
> > > > "java.lang.OutOfMemoryError"
> > > > So after each reset some object are not collected.. And some
> > > > references to objects are left.. I could't find where..
> > >
> > > I haven't looked into this in great detail, but I suspect that it's the
> > > same issue as discussed earlier, dealing with an alleged memory leak
> > > when the disable-caching vm property is set to true. The general idea:
> > > tapestry creates enhanced versions of the the classes, generating
> > > concrete accessors for you, etc. Each time you reset, new enhanced
> > > classes must be generated. But the JVM caches the classes, so,
> > > eventually, the jvm runs out of memory due to the cached class
> > > definitions, rather than any caching that tapestry is doing. Check out
> > > the recent thread on this subject with the disable-caching vm property
> > > set to true; somebody there posted a set of jvm arguments that seems to
> > > sidestep the problem.
> > >
> > > > IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
> > > > this insert)..
> > > > So maybe of component specifications it is leaking?
> > >
> > > Nope... your page has no properties in need of enhancement, but the
> > > insert component does. Taking the components out = a single class
> > > definition; putting the component in means each reset generates a new
> > > enhanced insert class.
> > >
> > > Robert
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Geoff Longman <gl...@gmail.com>.
Perhaps it is a bug but I don't see the reasoning for doing what you
are doing in the first place.
Why are you trying to clean out the pool?
Geoff
On 6/20/05, Tomas Jucius <en...@gmail.com> wrote:
> The Java Language Specification allows for the unloading of classes..
> And it is done during garbage collection...
>
> So it is tapestry bug..
>
> On 6/20/05, Robert Zeigler <rdzeigle@u.arizona.edu > wrote:
> > Tomas Jucius wrote:
> > > Here what I have found.. I can't develop my project because of this..
> > > Because it depends on this feature..
> > >
> > > As we all know tapestry put all things into pool ant it retrieves it
> > > when you request for page and etc...
> > >
> > > My application sometimes need to reset this pool..
> >
> > ?? What for? Aside from the development cycle, I can't think of any
> > reason to reset the pool. It's generally considered a bad idea to have
> > the reset service enabled during deployment.
> >
> > >
> > > So I use reset service..
> > >
> > > But after a lot of resets jvm memory becomes full, and I get
> > > "java.lang.OutOfMemoryError"
> > > So after each reset some object are not collected.. And some
> > > references to objects are left.. I could't find where..
> >
> > I haven't looked into this in great detail, but I suspect that it's the
> > same issue as discussed earlier, dealing with an alleged memory leak
> > when the disable-caching vm property is set to true. The general idea:
> > tapestry creates enhanced versions of the the classes, generating
> > concrete accessors for you, etc. Each time you reset, new enhanced
> > classes must be generated. But the JVM caches the classes, so,
> > eventually, the jvm runs out of memory due to the cached class
> > definitions, rather than any caching that tapestry is doing. Check out
> > the recent thread on this subject with the disable-caching vm property
> > set to true; somebody there posted a set of jvm arguments that seems to
> > sidestep the problem.
> >
> > > IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
> > > this insert)..
> > > So maybe of component specifications it is leaking?
> >
> > Nope... your page has no properties in need of enhancement, but the
> > insert component does. Taking the components out = a single class
> > definition; putting the component in means each reset generates a new
> > enhanced insert class.
> >
> > Robert
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Tomas Jucius <en...@gmail.com>.
The Java Language Specification allows for the unloading of classes..
And it is done during garbage collection...
So it is tapestry bug..
On 6/20/05, Robert Zeigler <rd...@u.arizona.edu> wrote:
> Tomas Jucius wrote:
> > Here what I have found.. I can't develop my project because of this..
> > Because it depends on this feature..
> >
> > As we all know tapestry put all things into pool ant it retrieves it
> > when you request for page and etc...
> >
> > My application sometimes need to reset this pool..
>
> ?? What for? Aside from the development cycle, I can't think of any
> reason to reset the pool. It's generally considered a bad idea to have
> the reset service enabled during deployment.
>
> >
> > So I use reset service..
> >
> > But after a lot of resets jvm memory becomes full, and I get
> > "java.lang.OutOfMemoryError"
> > So after each reset some object are not collected.. And some
> > references to objects are left.. I could't find where..
>
> I haven't looked into this in great detail, but I suspect that it's the
> same issue as discussed earlier, dealing with an alleged memory leak
> when the disable-caching vm property is set to true. The general idea:
> tapestry creates enhanced versions of the the classes, generating
> concrete accessors for you, etc. Each time you reset, new enhanced
> classes must be generated. But the JVM caches the classes, so,
> eventually, the jvm runs out of memory due to the cached class
> definitions, rather than any caching that tapestry is doing. Check out
> the recent thread on this subject with the disable-caching vm property
> set to true; somebody there posted a set of jvm arguments that seems to
> sidestep the problem.
>
> > IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
> > this insert)..
> > So maybe of component specifications it is leaking?
>
> Nope... your page has no properties in need of enhancement, but the
> insert component does. Taking the components out = a single class
> definition; putting the component in means each reset generates a new
> enhanced insert class.
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Tomas Jucius <en...@gmail.com>.
The Java Language Specification allows for the unloading of classes..
And it is done during garbage collection...
So it is tapestry bug..
On 6/20/05, Robert Zeigler <rd...@u.arizona.edu> wrote:
> Tomas Jucius wrote:
> > Here what I have found.. I can't develop my project because of this..
> > Because it depends on this feature..
> >
> > As we all know tapestry put all things into pool ant it retrieves it
> > when you request for page and etc...
> >
> > My application sometimes need to reset this pool..
>
> ?? What for? Aside from the development cycle, I can't think of any
> reason to reset the pool. It's generally considered a bad idea to have
> the reset service enabled during deployment.
>
> >
> > So I use reset service..
> >
> > But after a lot of resets jvm memory becomes full, and I get
> > "java.lang.OutOfMemoryError"
> > So after each reset some object are not collected.. And some
> > references to objects are left.. I could't find where..
>
> I haven't looked into this in great detail, but I suspect that it's the
> same issue as discussed earlier, dealing with an alleged memory leak
> when the disable-caching vm property is set to true. The general idea:
> tapestry creates enhanced versions of the the classes, generating
> concrete accessors for you, etc. Each time you reset, new enhanced
> classes must be generated. But the JVM caches the classes, so,
> eventually, the jvm runs out of memory due to the cached class
> definitions, rather than any caching that tapestry is doing. Check out
> the recent thread on this subject with the disable-caching vm property
> set to true; somebody there posted a set of jvm arguments that seems to
> sidestep the problem.
>
> > IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
> > this insert)..
> > So maybe of component specifications it is leaking?
>
> Nope... your page has no properties in need of enhancement, but the
> insert component does. Taking the components out = a single class
> definition; putting the component in means each reset generates a new
> enhanced insert class.
>
> Robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Robert Zeigler <rd...@u.arizona.edu>.
Tomas Jucius wrote:
> Here what I have found.. I can't develop my project because of this..
> Because it depends on this feature..
>
> As we all know tapestry put all things into pool ant it retrieves it
> when you request for page and etc...
>
> My application sometimes need to reset this pool..
?? What for? Aside from the development cycle, I can't think of any
reason to reset the pool. It's generally considered a bad idea to have
the reset service enabled during deployment.
>
> So I use reset service..
>
> But after a lot of resets jvm memory becomes full, and I get
> "java.lang.OutOfMemoryError"
> So after each reset some object are not collected.. And some
> references to objects are left.. I could't find where..
I haven't looked into this in great detail, but I suspect that it's the
same issue as discussed earlier, dealing with an alleged memory leak
when the disable-caching vm property is set to true. The general idea:
tapestry creates enhanced versions of the the classes, generating
concrete accessors for you, etc. Each time you reset, new enhanced
classes must be generated. But the JVM caches the classes, so,
eventually, the jvm runs out of memory due to the cached class
definitions, rather than any caching that tapestry is doing. Check out
the recent thread on this subject with the disable-caching vm property
set to true; somebody there posted a set of jvm arguments that seems to
sidestep the problem.
> IF THEREIS NO ANY COMPONENT in page when it is not leaking (so I put
> this insert)..
> So maybe of component specifications it is leaking?
Nope... your page has no properties in need of enhancement, but the
insert component does. Taking the components out = a single class
definition; putting the component in means each reset generates a new
enhanced insert class.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Michael Echerer <me...@tngtech.com>.
Hi,
have you tried to increase the JVM's permanent memory size? You
obviously tried -Xmx to increase the heap to 3GB, but maybe try:
-XX:PermSize=???m
-XX:MaxPermSize=???m
setting this will cause the permanent memory to take a bigger part of
the heap as set by -Xmx.
Of course, this will not stop memory leakage, but depending on how often
you reset, you might be able to shift e.g. container restarts into night
time maintainance slots or something like that and get away with it.
Also make sure that you didn't disable class garbage collection. Maybe
it helps to monitor the GC activities by logging things with
-Xloggc:<file> etc.
E.g. if it's really a problem about "classes" gc, the runtime's
freeMemory method won't tell you anything, if you're low on permanent
memory and simply throws out of memory errors.
Cheers
Michael
P.S. Might be useful for tuning and logging:
http://java.sun.com/docs/hotspot/gc1.4.2/
http://java.sun.com/docs/hotspot/VMOptions.html
Tomas Jucius wrote:
> If I clean all ognl properties... The applicaiontion can't load,
> because all beans ant other stuff disappears..
>
> How easy I could get the state of OGNL properties like in just
> initialized application?
>
> On 6/21/05, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>>My theory is that the code related to Introspector and OGNL is holding
>>onto references to outdated classes.
>>
>>On 6/21/05, Michael Musson <mu...@gmail.com> wrote:
>>
>>>On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
>>>
>>>>But after a lot of resets jvm memory becomes full, and I get
>>>>"java.lang.OutOfMemoryError"
>>>
>>>This issue has been raised in a previous thread. It was found that
>>>setting the property disable-caching to true would eventually lead to
>>>an out of memory exception and that setting the property to false
>>>would prevent the exception from occurring. However since you are
>>>calling the reset service you are creating the same situation through
>>>different means.
>>>
>>>Here is Johan's original message below summarizing what he found:
>>>
>>>When I looked at this in Jan 31 (see archives) the error I ran into
>>>was an OOME. When I looked at the actual stack-trace I could see that
>>>it was the permanent heap that was out of memory. This is significant
>>>since the permanent heap is used for storing classes and types. I have
>>>never seen a profiler that analyses the permanent heap in detail - it
>>>would be interesting to know if someone knows if such a tool exists.
>>>The permanent heap is most probably never garbage collected, this
>>>would amount to throwing away class definitions. This is usually not a
>>>problem since an ordinary application has a finite number of classes
>>>defined and when they are loaded that is it.
>>>Now, when in development mode I assume, and this is just a guess, that
>>>Tapestry is enhancing and creating _new_ classes every time a page is
>>>loaded. This will fill the permanent heap after a while and when that
>>>is full you'll get OOME.
>>>When Tapestry can cache the classes it creates the permanent heap will
>>>not fill up with new classes and everything should work as expected.
>>>So this will only be a problem when in development mode, I wouldn't
>>>even consider it a bug in Tapestry (this can happen with JSP compilers
>>>also), merely a fact of life as a developer :-)
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>>
>>>
>>
>>
>>--
>>Howard M. Lewis Ship
>>Independent J2EE / Open-Source Java Consultant
>>Creator, Jakarta Tapestry
>>Creator, Jakarta HiveMind
>>
>>Professional Tapestry training, mentoring, support
>>and project work. http://howardlewisship.com
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Tomas Jucius <en...@gmail.com>.
If I clean all ognl properties... The applicaiontion can't load,
because all beans ant other stuff disappears..
How easy I could get the state of OGNL properties like in just
initialized application?
On 6/21/05, Howard Lewis Ship <hl...@gmail.com> wrote:
> My theory is that the code related to Introspector and OGNL is holding
> onto references to outdated classes.
>
> On 6/21/05, Michael Musson <mu...@gmail.com> wrote:
> > On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
> > > But after a lot of resets jvm memory becomes full, and I get
> > > "java.lang.OutOfMemoryError"
> >
> > This issue has been raised in a previous thread. It was found that
> > setting the property disable-caching to true would eventually lead to
> > an out of memory exception and that setting the property to false
> > would prevent the exception from occurring. However since you are
> > calling the reset service you are creating the same situation through
> > different means.
> >
> > Here is Johan's original message below summarizing what he found:
> >
> > When I looked at this in Jan 31 (see archives) the error I ran into
> > was an OOME. When I looked at the actual stack-trace I could see that
> > it was the permanent heap that was out of memory. This is significant
> > since the permanent heap is used for storing classes and types. I have
> > never seen a profiler that analyses the permanent heap in detail - it
> > would be interesting to know if someone knows if such a tool exists.
> > The permanent heap is most probably never garbage collected, this
> > would amount to throwing away class definitions. This is usually not a
> > problem since an ordinary application has a finite number of classes
> > defined and when they are loaded that is it.
> > Now, when in development mode I assume, and this is just a guess, that
> > Tapestry is enhancing and creating _new_ classes every time a page is
> > loaded. This will fill the permanent heap after a while and when that
> > is full you'll get OOME.
> > When Tapestry can cache the classes it creates the permanent heap will
> > not fill up with new classes and everything should work as expected.
> > So this will only be a problem when in development mode, I wouldn't
> > even consider it a bug in Tapestry (this can happen with JSP compilers
> > also), merely a fact of life as a developer :-)
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant
> Creator, Jakarta Tapestry
> Creator, Jakarta HiveMind
>
> Professional Tapestry training, mentoring, support
> and project work. http://howardlewisship.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Howard Lewis Ship <hl...@gmail.com>.
My theory is that the code related to Introspector and OGNL is holding
onto references to outdated classes.
On 6/21/05, Michael Musson <mu...@gmail.com> wrote:
> On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
> > But after a lot of resets jvm memory becomes full, and I get
> > "java.lang.OutOfMemoryError"
>
> This issue has been raised in a previous thread. It was found that
> setting the property disable-caching to true would eventually lead to
> an out of memory exception and that setting the property to false
> would prevent the exception from occurring. However since you are
> calling the reset service you are creating the same situation through
> different means.
>
> Here is Johan's original message below summarizing what he found:
>
> When I looked at this in Jan 31 (see archives) the error I ran into
> was an OOME. When I looked at the actual stack-trace I could see that
> it was the permanent heap that was out of memory. This is significant
> since the permanent heap is used for storing classes and types. I have
> never seen a profiler that analyses the permanent heap in detail - it
> would be interesting to know if someone knows if such a tool exists.
> The permanent heap is most probably never garbage collected, this
> would amount to throwing away class definitions. This is usually not a
> problem since an ordinary application has a finite number of classes
> defined and when they are loaded that is it.
> Now, when in development mode I assume, and this is just a guess, that
> Tapestry is enhancing and creating _new_ classes every time a page is
> loaded. This will fill the permanent heap after a while and when that
> is full you'll get OOME.
> When Tapestry can cache the classes it creates the permanent heap will
> not fill up with new classes and everything should work as expected.
> So this will only be a problem when in development mode, I wouldn't
> even consider it a bug in Tapestry (this can happen with JSP compilers
> also), merely a fact of life as a developer :-)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Markus Eberle <Ma...@tngtech.com>.
Hi,
this problem is common to Tomcat, as the problem is in the classloader, some
thoughts about this can be found at
http://www.patrickpeak.com/page/patrick/20050614#your_web_app_is_leaking
Cheers,
Markus
> Hello,
>
> I've also run into this problem during development AND on our live
> production environment. We have a production server which we run Tomcat on.
> The different web applications share the same JVM. This is because we don't
> have infinite hardware, else we would have had more servers and one JVM per
> site. Now, when we want to update a site, we simply stop the web application
> (in tomcat's manager), deploy the new JAR's and other files, start the
> application and it's running again without the other sites being interupted.
> If we do this too many times, we get an OOME. I understand that this is not
> a Tapestry bug, but maybe someone can share some thoughts on how to fix
> this?
>
> Thanks,
>
> Niklas
>
> -----Ursprungligt meddelande-----
> Från: Michael Musson [mailto:musson.michael@gmail.com]
> Skickat: den 21 juni 2005 07:37
> Till: Tapestry users
> Kopia: Tomas Jucius
> Ämne: Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
>
> On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
> > But after a lot of resets jvm memory becomes full, and I get
> > "java.lang.OutOfMemoryError"
>
> This issue has been raised in a previous thread. It was found that setting
> the property disable-caching to true would eventually lead to an out of
> memory exception and that setting the property to false would prevent the
> exception from occurring. However since you are calling the reset service
> you are creating the same situation through different means.
>
> Here is Johan's original message below summarizing what he found:
>
> When I looked at this in Jan 31 (see archives) the error I ran into was an
> OOME. When I looked at the actual stack-trace I could see that it was the
> permanent heap that was out of memory. This is significant since the
> permanent heap is used for storing classes and types. I have never seen a
> profiler that analyses the permanent heap in detail - it would be
> interesting to know if someone knows if such a tool exists.
> The permanent heap is most probably never garbage collected, this would
> amount to throwing away class definitions. This is usually not a problem
> since an ordinary application has a finite number of classes defined and
> when they are loaded that is it.
> Now, when in development mode I assume, and this is just a guess, that
> Tapestry is enhancing and creating _new_ classes every time a page is
> loaded. This will fill the permanent heap after a while and when that is
> full you'll get OOME.
> When Tapestry can cache the classes it creates the permanent heap will not
> fill up with new classes and everything should work as expected.
> So this will only be a problem when in development mode, I wouldn't even
> consider it a bug in Tapestry (this can happen with JSP compilers also),
> merely a fact of life as a developer :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Niklas Ekman <ni...@citat.se>.
Hello,
I've also run into this problem during development AND on our live
production environment. We have a production server which we run Tomcat on.
The different web applications share the same JVM. This is because we don't
have infinite hardware, else we would have had more servers and one JVM per
site. Now, when we want to update a site, we simply stop the web application
(in tomcat's manager), deploy the new JAR's and other files, start the
application and it's running again without the other sites being interupted.
If we do this too many times, we get an OOME. I understand that this is not
a Tapestry bug, but maybe someone can share some thoughts on how to fix
this?
Thanks,
Niklas
-----Ursprungligt meddelande-----
Från: Michael Musson [mailto:musson.michael@gmail.com]
Skickat: den 21 juni 2005 07:37
Till: Tapestry users
Kopia: Tomas Jucius
Ämne: Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
> But after a lot of resets jvm memory becomes full, and I get
> "java.lang.OutOfMemoryError"
This issue has been raised in a previous thread. It was found that setting
the property disable-caching to true would eventually lead to an out of
memory exception and that setting the property to false would prevent the
exception from occurring. However since you are calling the reset service
you are creating the same situation through different means.
Here is Johan's original message below summarizing what he found:
When I looked at this in Jan 31 (see archives) the error I ran into was an
OOME. When I looked at the actual stack-trace I could see that it was the
permanent heap that was out of memory. This is significant since the
permanent heap is used for storing classes and types. I have never seen a
profiler that analyses the permanent heap in detail - it would be
interesting to know if someone knows if such a tool exists.
The permanent heap is most probably never garbage collected, this would
amount to throwing away class definitions. This is usually not a problem
since an ordinary application has a finite number of classes defined and
when they are loaded that is it.
Now, when in development mode I assume, and this is just a guess, that
Tapestry is enhancing and creating _new_ classes every time a page is
loaded. This will fill the permanent heap after a while and when that is
full you'll get OOME.
When Tapestry can cache the classes it creates the permanent heap will not
fill up with new classes and everything should work as expected.
So this will only be a problem when in development mode, I wouldn't even
consider it a bug in Tapestry (this can happen with JSP compilers also),
merely a fact of life as a developer :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: HUGE BUG - MEMORY LEAK IN TAPESTRY 3.0.3!!! - PLEASE SUPPORT
Posted by Michael Musson <mu...@gmail.com>.
On 6/17/05, Tomas Jucius <en...@gmail.com> wrote:
> But after a lot of resets jvm memory becomes full, and I get
> "java.lang.OutOfMemoryError"
This issue has been raised in a previous thread. It was found that
setting the property disable-caching to true would eventually lead to
an out of memory exception and that setting the property to false
would prevent the exception from occurring. However since you are
calling the reset service you are creating the same situation through
different means.
Here is Johan's original message below summarizing what he found:
When I looked at this in Jan 31 (see archives) the error I ran into
was an OOME. When I looked at the actual stack-trace I could see that
it was the permanent heap that was out of memory. This is significant
since the permanent heap is used for storing classes and types. I have
never seen a profiler that analyses the permanent heap in detail - it
would be interesting to know if someone knows if such a tool exists.
The permanent heap is most probably never garbage collected, this
would amount to throwing away class definitions. This is usually not a
problem since an ordinary application has a finite number of classes
defined and when they are loaded that is it.
Now, when in development mode I assume, and this is just a guess, that
Tapestry is enhancing and creating _new_ classes every time a page is
loaded. This will fill the permanent heap after a while and when that
is full you'll get OOME.
When Tapestry can cache the classes it creates the permanent heap will
not fill up with new classes and everything should work as expected.
So this will only be a problem when in development mode, I wouldn't
even consider it a bug in Tapestry (this can happen with JSP compilers
also), merely a fact of life as a developer :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org