gt; > > >This was specifically blamed on the JVM, and not a Tomcat bug. The
> > fact
> > > that
> > > >it seems to happen with JBoss as well would tend to support that
> > > assertion.
> > > >
> > > >-Jason
> > > >
> >
t
> > >it seems to happen with JBoss as well would tend to support that
> > assertion.
> > >
> > >-Jason
> > >
> > >On Wednesday 25 January 2006 10:52, Sergiy Kyrylkov wrote:
> > >
> > >
> > >>Here is more
> > >
makes you think it is a JVM issue?
> >>
> >>Sergiy
> >>
> >>
> >>
> >>>-Original Message-
> >>>From: Jason Dyer [mailto:[EMAIL PROTECTED]
> >>>Sent: Wednesday, January 25, 2006 5:44 PM
> >>>To: Ta
Dyer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, January 25, 2006 5:44 PM
To: Tapestry users
Subject: Re: OutOfMemoryError
I had the same problem with tomcat. You can delay it by increasing
permanent
memory to the JVM, but the only real fix seems to be restarting on
deploy...
Apparently this is
moryExceptions
>
> Jason, what makes you think it is a JVM issue?
>
> Sergiy
>
> > -Original Message-
> > From: Jason Dyer [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, January 25, 2006 5:44 PM
> > To: Tapestry users
> > Subject: Re: OutOfMemoryError
Here is more
http://wiki.jboss.org/wiki/Wiki.jsp?page=OutOfMemoryExceptions
Jason, what makes you think it is a JVM issue?
Sergiy
> -Original Message-
> From: Jason Dyer [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 25, 2006 5:44 PM
> To: Tapestry users
&
I had the same problem with tomcat. You can delay it by increasing permanent
memory to the JVM, but the only real fix seems to be restarting on deploy...
Apparently this is a JVM issue, not particular to any app server.
On Wednesday 25 January 2006 10:38, Cliff Zhao wrote:
> After several time
You have to allocate more space for permanent object space using
java -XX:MaxPermSize=128m
or whatever you want instead of 128 MB.
Sergiy
==
Multiplex Systems LLC
http://www.mpxsys.com
==
> -Original Message-
> From: Cliff Zhao [mailto:[EMAIL PR
, October 06, 2005 4:15 PM
To: 'Tapestry users'
Subject: RE: OutOfMemoryError Tapestry 4.0
I had some success with an approach like you describe in an old
system where I was doing runtime code generation and compilation (nothing
too sophisticated, I was manually writing legal
To: tapestry-user@jakarta.apache.org
> Subject: Re: OutOfMemoryError Tapestry 4.0
>
> Could some artificial restrictions on the pages, components, beans
> whatever
> lower the natural java + vm limits that eventually reload is possible?
>
> As far I get it the problems are mainly due to a missi
ble? having any great ideas?
-Ursprüngliche Nachricht-
Von: Hensley, Richard [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 6. Oktober 2005 19:34
An: Tapestry users
Betreff: RE: OutOfMemoryError Tapestry 4.0
Playing with class loaders in Java is kind like playing with fire with
only a small bucket of water
e Nachricht-
Von: Hensley, Richard [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 6. Oktober 2005 19:34
An: Tapestry users
Betreff: RE: OutOfMemoryError Tapestry 4.0
Playing with class loaders in Java is kind like playing with fire with
only a small bucket of water around.
You can do it, but
>
>
> -Ursprüngliche Nachricht-
> Von: Hensley, Richard [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 6. Oktober 2005 19:34
> An: Tapestry users
> Betreff: RE: OutOfMemoryError Tapestry 4.0
>
>
> Playing with class loaders in Java is kind like playing with f
ley, Richard [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, October 06, 2005 10:24 AM
> > To: Tapestry users
> > Subject: RE: OutOfMemoryError Tapestry 4.0
> >
> > Generated Classes are loaded into a class loader so they can be
> > instantiated
> > by Tapestry
rd
-Original Message-
From: Patrick Casey [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 06, 2005 10:30 AM
To: 'Tapestry users'
Subject: RE: OutOfMemoryError Tapestry 4.0
Isn't the major source of the OP's memory use though the 600+ new
instances of javassist.Ct
t;[EMAIL PROTECTED]> wrote:
Shouldn't the old ones go out of scope though and get gc'd?
--- Pat
-Original Message-
From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 06, 2005 9:52 AM
To: Tapestry users; [EMAIL PROTECTED]
Subject: Re: OutOfMem
AM
To: Tapestry users
Subject: RE: OutOfMemoryError Tapestry 4.0
wouldn't it be a good thing to use a
discardable class loader in dev-mode?
> --- Ursprüngliche Nachricht ---
> Von: "Hensley, Richard" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betr
r 06, 2005 10:24 AM
> To: Tapestry users
> Subject: RE: OutOfMemoryError Tapestry 4.0
>
> Generated Classes are loaded into a class loader so they can be
> instantiated
> by Tapestry and Hivemind. The only way to release the generated classes is
> to release the class loader.
>
&g
wouldn't it be a good thing to use a
discardable class loader in dev-mode?
> --- Ursprüngliche Nachricht ---
> Von: "Hensley, Richard" <[EMAIL PROTECTED]>
> An: "Tapestry users"
> Betreff: RE: OutOfMemoryError Tapestry 4.0
> Datum: Thu, 6
cenzi [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 06, 2005 10:10 AM
To: Tapestry users
Subject: Re: OutOfMemoryError Tapestry 4.0
Howard Lewis Ship escribió:
>That might be reasonable if you are running with
>-Dorg.apache.tapestry.disable-caching=true
>
>With caching disabled
Shouldn't the old ones go out of scope though and get gc'd?
--- Pat
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Thursday, October 06, 2005 9:52 AM
> To: Tapestry users; [EMAIL PROTECTED]
> Subject: Re: OutO
Howard Lewis Ship escribió:
That might be reasonable if you are running with
-Dorg.apache.tapestry.disable-caching=true
With caching disabled, Tapestry has to constantly create new enhanced
subclasses for every page and every component.
Shouldn't it delete old classes?
--
nce the number of pages that can be successfully
> > rendered before an OutOfMemoryError exception occurs is reduced by
> > changing
> > pages the problem resides at the presentation (Tapestry) level.
> >
> > Any thoughts?
> >
> > Paul
> >
> >
&g
That looks like it'd work, yep. Dunno if the Hibernate session is
> the root of your bug, but A) it might be and B) that looks like it'll
> clear
> it out.
>
> --- Pat
>
> >-Original Message-
> >From: seloha . [mailto:[EMAIL PROTECTED]
> >
Monday, September 26, 2005 1:15 PM
To: tapestry-user@jakarta.apache.org
Subject: RE: OutOfMemoryError Tapestry 4.0
Pat,
So in my case then since the Hibernate session is controlled by Spring
after
getting the large list I could subsequently call a method in my DAO which
looks something li
, 2005 1:15 PM
> To: tapestry-user@jakarta.apache.org
> Subject: RE: OutOfMemoryError Tapestry 4.0
>
> Pat,
>
> So in my case then since the Hibernate session is controlled by Spring
> after
> getting the large list I could subsequently call a method in my DAO which
&g
;
List l = q.list();
For (int x=0; x< l.size(); x++)
s.evict(l.get(x));
-Original Message-
From: seloha . [mailto:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 12:45 PM
To: tapestry-user@jakarta.apache.org
Subject: RE: OutOfMemoryError Tapestry 4.0
Pat,
You were right to suggest it, it can't hurt.
Mark
-Original Message-
From: Patrick Casey [mailto:[EMAIL PROTECTED]
Sent: Mon 9/26/2005 2:08 PM
To: 'Tapestry users'
Subject: RE: OutOfMemoryError Tapestry 4.0
True, but it's better than not asking at all
Pat
> -Original Message-
> From: Mark Stang [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 26, 2005 1:02 PM
> To: Tapestry users; tapestry-user@jakarta.apache.org
> Subject: RE: OutOfMemoryError Tapestry 4.0
>
> I don't believe that calling System.gc() will have
I don't believe that calling System.gc() will have the immediate affect you
require. The call is more of a request than a command.
-Original Message-
From: seloha . [mailto:[EMAIL PROTECTED]
Sent: Mon 9/26/2005 12:54 PM
To: tapestry-user@jakarta.apache.org
Subject: RE: OutOfMemory
26, 2005 12:45 PM
> To: tapestry-user@jakarta.apache.org
> Subject: RE: OutOfMemoryError Tapestry 4.0
>
> Pat,
>
> 1) Yes I am setting the object list to null.
>
> 2) I have not put a log statement in the code to check it but I have set a
> break point in debug mod
]
Sent: Monday, September 26, 2005 11:55 AM
To: tapestry-user@jakarta.apache.org
Subject: RE: OutOfMemoryError Tapestry 4.0
Thanks Pat,
One thing I was not doing which you pointed out was setting the list to
null
in pageDetached(PageEvent event) so I added this and also included
System.gc(). This unfor
Paul,
Instead of poking in the dark, get your boss (assuming you have one :-))
to buy you a good memory profiler like YourKit (http://www.yourkit.com)
or JProbe (http://www.quest.com/jprobe/) and you will be golden.
Serge
P.S. YourKit is just great...
seloha . wrote:
Yes I do in the develop
e lifespan of the session, regardless of whether or not your
code holds a reference to them.
> -Original Message-
> From: seloha . [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 26, 2005 11:55 AM
> To: tapestry-user@jakarta.apache.org
> Subject: RE: OutOfMemoryError
Yes I do in the development system but in the different production test
systems caching is enabled.
regards
Paul
Mind Bridge <[EMAIL PROTECTED]> wrote:
Do you have caching disabled by any chance?
seloha . wrote:
Thanks ausias,
I have thought about reducing the number of ob
Thanks Pat,
One thing I was not doing which you pointed out was setting the list to null
in pageDetached(PageEvent event) so I added this and also included
System.gc(). This unfortunately had no affect. The list uses abstract getter
and setter and is initialized in the .page spec with
initial
em?
--- Pat
> -Original Message-
> From: Howard Lewis Ship [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 26, 2005 11:45 AM
> To: Tapestry users
> Subject: Re: OutOfMemoryError Tapestry 4.0
>
> The likely difference is how Tapestry renders the page; i
The likely difference is how Tapestry renders the page; it will buffer
the contents in memory (a consequence of the Body component) before
streaming the entire result to the user. If your page does not use
any JavaScript, then you should be able to build it without the Body
component and the resul
Do you have caching disabled by any chance?
seloha . wrote:
Thanks ausias,
I have thought about reducing the number of objects but a prvious
version of the app written with struts was able to display many more
thn 5000 lines with no problem. A rethink on presentation may be a
good idea. Als
Thanks ausias,
I have thought about reducing the number of objects but a prvious version of
the app written with struts was able to display many more thn 5000 lines
with no problem. A rethink on presentation may be a good idea. Also
providing the container with more memory may help.
Thanks a
It sounds like a memory leak, but it could just be a slow garbage
collector as well. Try adding:
System.gc() to the end of your transaction to guarantee the garbage
collector runs after each page render. Then see if repeated page renders
still blow out your memory. If they do, the
Hi,
In my experience, the problem you're describing is not
related directly with Tapestry, It looks like more as
a standard problem with the available memory in the
servlet container.
I'll try to avoid returning 5000 objects at the same
time, depending on the size of the objects this can be
a l
42 matches
Mail list logo
