Re: java.lang.OutOfMemoryError: unable to create new native thread

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

angela19800727_at_gmail.com wrote:
> 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.execute(PooledExecutor.java:
> 978)
> 07/06/13 08:01:03 at
> com.evermind.util.ThreadPool.launch(ThreadPool.java: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.
>
Platform would help, although I am assuming here, it is not Windows.

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+Lw8L4IAs830RAhXDAJ95AxRSEuNUZwWzdvlQzljv17aUFwCffnxg oYR3pFa2Yc9VbzoA6/fAEFc=
=EU5w
-----END PGP SIGNATURE----- Received on Sun Sep 09 2007 - 12:37:50 CEST