Notice to Sender
================
This message was received by this installation but could not be
delivered to its intended cc:Mail recipient(s).
Original subject: Unsent Message Returned to Sender
Intended recipient(s) who DID NOT receive this message:
[EMAIL PROTECTED]
The following cc:Mail error(s) were recorded:
*** Message recipient is unknown ***
-------- Original Message Text --------
Notice to Sender
================
This message was received by this installation but could not be
delivered to its intended cc:Mail recipient(s).
Original subject: Re: RE: Garbage collection, out of memory
Intended recipient(s) who DID NOT receive this message:
[EMAIL PROTECTED]
The following cc:Mail error(s) were recorded:
*** Message recipient is unknown ***
-------- Original Message Text --------
The problem is not that simple. There's a bug.
We then ran a test program that creates a simple entity bean in an infinite
loop and then releases the reference of this entity bean. We ran a profiler
on the VM and counted the memory instances. The server keeps the beans in a
list, so the GC cant have them, and it turns out that even though memory
seems to be running out, orion does not passivate.
We told them, and [EMAIL PROTECTED] said thanx and they'd fix it, but
they cannot give an estimate of when - we've been waiting for 3 months now.
Up to 1.4.5 you could not limit the pool size, so there aint no way to force
it to start passivating.
Regards
Jaco
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
Sent: 13 February 2001 23:32
To: Orion-Interest
Subject: Re: Garbage collection, out of memory
Your GC times are huge because you have provided so much memory. If you
reduce the 500MB to 128MB, you will see more GC's, but they will be much
shorter. This is a well known optimization issue. Too little memory causes
to many GC runs, while too much memory causes GC runs to be too long. You
need to experiment to find the best amount of memory to allocate.
tim.
> Hello
>
> We are experiencing a garbage collection problem. We are running Orion
> 1.4.7 on a Linux 2.4 box. We have been trying the Sun 1.2.2, the Sun 1.3
> and the IBM JVM 1.3. On the Sun 1.3 JVM we have tried normal garbage
> collection and also -Xincgc incremental garbage collection. We run with
> 500 megabytes of heap space available to Java.
>
> The system uses lots of EJBs (mainly stateless session but also quite a
> few entities and a handful of stateful session beans), and we have JSP
> pages which run in the same JVM.
>
> The system runs very responsively and well, with up to 90 users
> simultaneously using it, for up to an hour. Then enormous GCs start
> happening which block all activity for up to 180 seconds at a time! The
> length and frequency of the freezes vary with the different JVMs but all
> are unusable after say an hour of up time.
>
> The Sun 1.3 in incremental GC mode is the best, and in fact remains stable
> and usable until it starts doing a few 9 second GCs from time to time
> (comparatively bearable) until we get a "HotSpot internal error" which
> stops all processing.
>
> We are trying all sorts of different things to stop our users getting
> upset, like reducing the JSP session timeout to a minimum, and are
> currently trying to analyse the code with JProbe to find out how to
> minimise unnecessary object creation or memory leaks (stale references to
> no longer used objects etc).
>
> As several list members have already said, it also seems that some beans
> are never passivated.
>
> What can we do to make Orion stop using more and more memory, and not to
> cause such outrageous garbage collection cycles?
>
> Any comments or suggestions would be very much appreciated.
>
> --
> Thomas Munro <[EMAIL PROTECTED]>
> http://www.fullsix.com/
> Fullsix Technology (Paris)
>
>
