Current problem reports assigned to freebsd-java@FreeBSD.org

[Ronald Klop]

On Mon, 11 Feb 2008 15:06:47 +0100, Eelco den Heijer  
<eelco at objectivation.nl> 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/freebsd-java/2007-July/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, 0x31670000)
compacting perm gen total 65536K, used 65535K [0x31670000, 0x35670000,  
0x35670000)
the space 65536K, 99% used [0x31670000, 0x3566fef8, 0x35670000, 0x35670000)
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 <pid> 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 not  
garbage collected.

Is this expected behaviour. You have more than one QuartzScheduler running.
** copy-paste from the issue:
0x0820b600 JavaThread "QuartzScheduler_Worker-1" [_thread_blocked,  
id=136361984]
...
0x08457000 JavaThread "QuartzScheduler_Worker-1" [_thread_blocked,  
id=138768896]
**

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