Please help!

Have seen this "java.lang.OutOfMemoryError: unable to create new
native thread" message in oracle application server(9.0.4.2)?

OC4J_BI_Forms crashed many times recently.
Client can't use in crashed time.

JVM memory is very enough and OS memory is very enough in that time.
Get error as following.
--------
07/06/09 09:33:33 Start process
--------
07/06/09 09:33:45 FormsServlet init():
configFileName: /home/oracle/forms/forms90/server/formsweb.cfg
testMode: false
07/06/09 09:33:46 Oracle Application Server Containers for J2EE 10g
(9.0.4.2.0) in
itialized
07/06/09 09:39:01 ListenerServlet init()
07/06/13 07:57:00 java.io.IOException: Resource temporarily
unavailable
07/06/13 08:00:41 Forms session <815> aborted: unable to communicate
with runtime process.
07/06/13 08:01:03 java.lang.OutOfMemoryError: unable to create new
native thread
07/06/13 08:01:03 at java.lang.Thread.start(Native Method)
07/06/13 08:01:03 at
com.evermind.util.ReleasableResourcePooledExecutor .addThread(ReleasableResourcePooledExecutor
..java:121)
07/06/13 08:01:03 at
EDU.oswego.cs.dl.util.concurrent.PooledExecutor.ex ecute(PooledExecutor.java:
978)
07/06/13 08:01:03 at
com.evermind.util.ThreadPool.launch(ThreadPool.jav a:255)
07/06/13 08:01:03 at
com.evermind.server.http.AJPConnectionListener.run (AJPConnectionListener.java:
74)
07/06/13 08:01:03 at com.evermind.util.ReleasableResourcePooledExecutor
$MyWorker.r
un(ReleasableResourcePooledExecutor.java:186)
07/06/13 08:01:03 at java.lang.Thread.run(Thread.java:534)
07/06/13 08:01:03 Forms session <816> aborted: unable to communicate
with runtime process.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

angela19800727 (AT) gmail (DOT) com wrote:

It looks as if you have a busy forms server here (process 815 and
816 crash within 20 seconds apart), but an out of memory error can
always be cured by throwing more memory: up the -MXM parameter
of you java process - you will have to find out if it's the
OC4J_BI_FORMS container, or the OC4J container, you run your
forms in (if/when you use a named configuration).

Apart from that, there should be a trace file, with more information
on the form, and what is was doing during the crash.
Some crashes are due to bugs, not the way things are designed.
Some are just design errors, some are plain upgrade errors.

Querying metalink will result in a multitude of notes, papers,
how-to's and problems. The FRM error stack at the client is very useful
information (and is missing here)
- --
Regards,
Frank van Bortel

Top-posting is one way to shut me up...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFG48z+Lw8L4IAs830RAhXDAJ95AxRSEuNUZwWzdvlQzl jv17aUFwCffnxg
oYR3pFa2Yc9VbzoA6/fAEFc=
=EU5w
-----END PGP SIGNATURE-----

OS version:Red Hat Enterprise Linux AS release 3 (Taroon Update 3).
What does the mxm mean?
The server is stable and os memory is very enough when running 300
users or 400 users.
OC4J_BI_Forms memory is very enough when running 300 users or 400
users.
We quried metalink about this case,but no solution for me.
Therefore,We must rely on ourselves.

On Sep 9, 6:37 pm, Frank van Bortel <frank.van.bor... (AT) gmail (DOT) com>
wrote: