On Mon, 11 Feb 2008 15:06:47 +0100, Eelco den Heijer =

wrote:

>
>> Current FreeBSD problem reports
>> Critical problems
>> Serious problems
>>
>> S Tracker Resp. Description
>> ---------------------------------------------------------------------=

-----------
>> o java/114644 java tomcat goes out of PermSpace, jvm crashes

> Hi, does anyone know whether anyone is working/looking
> at this issue? Apparantly it has been open since July 17th, 2007.
> I looked on =


> http://lists.freebsd.org/pipermail/f...ly/006476.html
> and 'State' is on 'open'.
>
> This issue is a bit of a showstopper for us at the moment; we are
> considering to move to another OS or another servlet container.
> Neither option appeals to us, but the 'random' crashes are getting
> annoying :-/
>
> Any info/advice will be appreciated,
> Best regards,
> Eelco den Heijer


This problem also happens on Linux and Windows.
Looking at your issue I think you are running with the default settings.=


** copy-paste from the issue:
Heap
def new generation total 4544K, used 0K [0x2d670000, 0x2db50000, =

0x2db50000)
eden space 4096K, 0% used [0x2d670000, 0x2d670000, 0x2da70000)
from space 448K, 0% used [0x2da70000, 0x2da70000, 0x2dae0000)
to space 448K, 0% used [0x2dae0000, 0x2dae0000, 0x2db50000)
tenured generation total 60544K, used 30895K [0x2db50000, 0x31670000, =

0x31670000)
the space 60544K, 51% used [0x2db50000, 0x2f97bc18, 0x2f97be00, 0x316700=
00)
compacting perm gen total 65536K, used 65535K [0x31670000, 0x35670000, =

0x35670000)
the space 65536K, 99% used [0x31670000, 0x3566fef8, 0x35670000, 0x356700=
00)
No shared spaces configured.
**

64MB for tenured and 64MB for perm gen.
Try increasing perm gen to 128MB and see what happens.
With the tool 'jstat -gc 1000' you watch memory usage of the =

different object generations in java.

Do you reload your context sometimes in Tomcat?
It is a known issue that with some singleton constructions you can keep =
=

the classloader referenced, so classes (which are in the perm gen) are n=
ot =

garbage collected.

Is this expected behaviour. You have more than one QuartzScheduler runni=
ng.
** copy-paste from the issue:
0x0820b600 JavaThread "QuartzScheduler_Worker-1" [_thread_blocked, =

id=3D136361984]
....
0x08457000 JavaThread "QuartzScheduler_Worker-1" [_thread_blocked, =

id=3D138768896]
**

It might be that reloading the context in Tomcat doesn't stop the Quartz=
=

threads, so all previous class remain referenced in memory.

Ronald.

-- =

Ronald Klop
Amsterdam, The Netherlands
_______________________________________________
freebsd-java@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"