spaway escribió:
many thanks,
I am using netbeans IDE and have updated netbeans.conf file in my home user
netbeans/6.1/etc folder as follows:
-J-Xss2m -J-Xms32m -J-XX:PermSize=64m -J-XX:MaxPermSize=1024m
That will only affect Netbeans itself, not the tomcat server your
application runs on,
many thanks,
I am using netbeans IDE and have updated netbeans.conf file in my home user
netbeans/6.1/etc folder as follows:
-J-Xss2m -J-Xms32m -J-XX:PermSize=64m -J-XX:MaxPermSize=1024m
the problems still persists after some building & re-deployment iterations.
whenever netbeans output Final Me
FYI PermGen space is the space used to hold classes. IN an app server
you often need more than the normal amount, since there is so much
extra code. Tapestry itself adds many dependencies, plus extra class
loaders, plus many runtime-generated classes. More PermGen space is a
good idea.
On Tue, Ju
-XX:PermSize=0m (default)
-XX:MaxPermSize=64m (default)
Example: JAVA_OPTS=-XX:PermSize=64m -XX:MaxPermSize=128m
On Tue, Jun 2, 2009 at 11:05 AM, Thiago H. de Paula Figueiredo <
thiag...@gmail.com> wrote:
> Try raising the permgen space maximum allocated memory.
>
> --
> Thiago
>
>
Try raising the permgen space maximum allocated memory.
--
Thiago
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
ch larger the PermSize can be.
>>
>> Thanks for your help.
>>
>>
>> -Original Message-
>> From: Martin Strand [mailto:[EMAIL PROTECTED]
>> Sent: Monday, July 24, 2006 10:31 AM
>> To: Tapestry users
>> Subject: Re: PermGen space - Cach
#x27;t know how much larger the PermSize can be.
Thanks for your help.
-Original Message-
From: Martin Strand [mailto:[EMAIL PROTECTED]
Sent: Monday, July 24, 2006 10:31 AM
To: Tapestry users
Subject: Re: PermGen space - Caching is ON
Hot redeploy is when you edit your code in Eclipse and
e PermSize can be.
Thanks for your help.
-Original Message-
From: Martin Strand [mailto:[EMAIL PROTECTED]
Sent: Monday, July 24, 2006 10:31 AM
To: Tapestry users
Subject: Re: PermGen space - Caching is ON
Hot redeploy is when you edit your code in Eclipse and Eclipse automatically
PermSize can be.
Thanks for your help.
-Original Message-
From: Konstantin Ignatyev [mailto:[EMAIL PROTECTED]
Sent: Monday, July 24, 2006 9:52 AM
To: Tapestry users
Subject: Re: PermGen space - Caching is ON
Just an idea: could it be that some aspectizing container (Spring or
Hiv
any ideas?
>
> -Original Message-
> From: James Carman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 23, 2006 6:03 AM
> To: Tapestry users
> Subject: Re: PermGen space
>
> Actually, Tapestry (and HiveMind as well) uses Javassist to generate
> classes at runtime,
Just an idea: could it be that some aspectizing
container (Spring or HiveMind)has a not quite
correctly written service that is not a singleton, but
a (bad) factory. That factory might create new
aspectized class every time and then instantiate
object instead of creating a weaved class once and
th
ssion that making it
> larger will just delay the OOM condition anyway.
>
> Anybody else have any ideas?
>
> -Original Message-
> From: James Carman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 23, 2006 6:03 AM
> To: Tapestry users
> Subject: Re: PermGen space
>
nal Message-
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 23, 2006 6:03 AM
To: Tapestry users
Subject: Re: PermGen space
Actually, Tapestry (and HiveMind as well) uses Javassist to generate
classes at runtime, but all the rest is still true with Javassist as it
is with CGLIB
On 7/24/06, Ben Sommerville <[EMAIL PROTECTED]> wrote:
A final option may be to use a different JDK impl. E.g. I'm pretty sure
that Jrockit (from bea) doesn't have a perm gen space & hence wont get the
same problem (or at least might manifest it in a different way that is
easier to diagnose).
Roughly 100 unique pages. Several pages have multiple Ajax round trips for
autocomplete using the Tacos toolkit.
-Original Message-
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Monday, July 24, 2006 5:03 AM
To: Tapestry users
Subject: RE: PermGen space - Caching is ON
How
gt; larger in production and it sounds from your discussion that making it
> larger will just delay the OOM condition anyway.
>
> Anybody else have any ideas?
>
> -Original Message-
> From: James Carman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, July 23, 2006 6:03 AM
"Harvey, David " <[EMAIL PROTECTED]> wrote on 24/07/2006 02:50:17:
> Thanks for your comments, discussion. However, this occurs when
> caching is turned on, i.e.
> -Dorg.apache.tapestry.disable-caching=false.
>
> I sure hope there's a fix, I don't know if MaxPermSize can be made
> any larger in
that helps.
For what its worth, you have my sympathies. I've tried to find similar
problems myself & itÂ’s a long, hard road :(
Regards,
Ben Sommerville
-Original Message-
From: Henri Dupre [mailto:[EMAIL PROTECTED]
Sent: Monday, 24 July 2006 2:12 PM
To: Tapestry users
Subject: Re: Perm
xPermSize can be made any
> larger in production and it sounds from your discussion that making it
> larger will just delay the OOM condition anyway.
>
> Anybody else have any ideas?
>
> -Original Message-
> From: James Carman [mailto:[EMAIL PROTECTED]
> Sent:
anyway.
Anybody else have any ideas?
-Original Message-
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 23, 2006 6:03 AM
To: Tapestry users
Subject: Re: PermGen space
Actually, Tapestry (and HiveMind as well) uses Javassist to generate
classes at runtime, but all the re
arger will
just delay the OOM condition anyway.
Anybody else have any ideas?
-Original Message-
From: James Carman [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 23, 2006 6:03 AM
To: Tapestry users
Subject: Re: PermGen space
Actually, Tapestry (and HiveMind as well) uses Javassist t
Actually, Tapestry (and HiveMind as well) uses Javassist to generate
classes at runtime, but all the rest is still true with Javassist as it is
with CGLIB (hibernate uses CGLIB). As Martin said, enabling caching
should fix the problem. Tapestry will only generate (and cache) the
classes for each
Hi all,
This problem is very common with Tapestry applications. This is due to
the fact that Tapestry uses cglib to generate classes at runtime.
Java uses a separate Heap space called "PermGenSpace" to put meta-data
about classes, which is never garbage collected (this is "normal" since
normall
I believe it has to do with Tapestry's class enhancing. If you disable
caching (which you would only do in a development environment) Tapestry
will re-enhance the component classes on every request, leaving the
classloader with more and more classes to keep track of.
Apparently, these classes
24 matches
Mail list logo
