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: 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 --------
Sounds good, but WHERE does these parameters go? I include a snippit of my
orion-ejb-jar.xml file...
<entity-deployment name="ejb/ActualBankControl"
location="ejb/ActualBankControl"
wrapper="ActualBankControlHome_EntityHomeWrapper78"
table="ejb/ActualBankControl">
<ejb-ref-mapping name="ejb/EventLogDB" />
<resource-ref-mapping name="jdbc/ActualBankControlDataSource" />
</entity-deployment>
Thanx
Jaco
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Doernberg
Sent: 14 February 2001 01:45
To: Orion-Interest
Subject: Re: Garbage collection, out of memory
When you deploy your application. Orion will generate an XML file called
orion-ejb-jar.xml, if one does not exist. The file is derived from your
EJBs. The file can be found buried in the application-deployments
directory.
You can set some parameters on each EJB you deem appropriate. These
parameters are not set in the auto generated file.
The first is a "validity-timeout" set to milliseconds. This will passivate
the the EJB if not active.
The second is a parameter called "max-instances" . This is set to the max
number of EJBs of a particular type you want. I am not sure if this is
supported yet, but I believe it was supposed to be implemented in the 1.4.7.
Hope this help. Let me know what you figure out.
-Mike
----- Original Message -----
From: "Thomas Munro" <[EMAIL PROTECTED]>
To: "Orion-Interest" <[EMAIL PROTECTED]>
Sent: Tuesday, February 13, 2001 1:29 PM
Subject: Garbage collection, out of memory
> 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)
>
>
