[omniORB] Exception trying to start new thread

[Harri Pasanen]

Just a note, that with omniORB you are also prone to run into open file 
descriptors limit before the thread limit, as each thread often has one or 
more file descriptors open.

-Harri

On Monday 03 April 2006 04:06, Luke Deller wrote:
> Hi Radek,
>
> On Fri, 2006-03-31 at 18:32 +0200, radamkie at kdm.pl wrote:
> > The platform is:
> >
> > OS:Red Hat Enterprise Linux AS release 3 (Taroon Update 5)
> > Kernel:Linux 2.4.21-32
> > Processor: Intel(R) Xeon 3GHz
> > RAM: 2GB
>
> I guess from your kernel name that you're running a 32-bit kernel; I
> take it that this model of Xeon doesn't support the EM64T extensions,
> which is a shame.
>
> > #cat /proc/sys/kernel/threads-max
> > 14336
>
> In practice you will be able to create far fewer threads than this in a
> single process using the default thread stack size, particularly if you
> are running a 32-bit kernel.
>
> You can see this using the attached c++ program; it will determine how
> many threads can be created on your system using the default thread
> stack size.
>
> > Is a way to check how many threads are working in omniORB application ?
>
> You could always attach to the process using gdb and type "info
> threads".
>
> I still believe that your problem is that omniORB is set to use too many
> threads.  Have you tried limiting omniORB to using say 100 threads?
> This should stop the error message.  For example you could try:
>
> threadPerConnectionPolicy = 1
> maxServerThreadPoolSize = 100
> threadPerConnectionUpperLimit = 50
> threadPerConnectionLowerLimit = 40
>
> Regards,
> Luke.
>
>
> ***************************************************************************
>*******************
>
> Important Note
> This email (including any attachments) contains information which is
> confidential and may be subject to legal privilege.  If you are not
> the intended recipient you must not use, distribute or copy this
> email.  If you have received this email in error please notify the
> sender immediately and delete this email. Any views expressed in this
> email are not necessarily the views of XPlan Technology.
>
> It is the duty of the recipient to virus scan and otherwise test the
> information provided before loading onto any computer system.
> Xplan Technology does not warrant that the
> information is free of a virus or any other defect or error.
> ***************************************************************************
>*******************


Privileged or confidential information may be contained in this message.  If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Trema does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Trema does not accept liability for any damage sustained as a result of viruses.  Statements in this message or attachments that do not relate to the business of Trema are neither given nor endorsed by the company or its directors. A list of Trema's directors is available on our web site: www.trema.com