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

From: angela <angela19800727_at_gmail.com>
Date: Tue, 11 Sep 2007 13:21:15 -0000
Message-ID: <1189516875.683886.243030_at_d55g2000hsg.googlegroups.com>


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.

[Quoted] On Sep 9, 6:37 pm, Frank van Bortel <frank.van.bor..._at_gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>
>
> angela19800..._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(ReleasableReso­urcePooledExecutor
> > .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.ja­va:
> > 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------ Hide quoted text -
>
> - Show quoted text -
Received on Tue Sep 11 2007 - 15:21:15 CEST

Original text of this message