[omniORB] Naming Service

[Duncan Grisby]

On Wednesday 8 August, Richard Hardgrave wrote:

> I'm getting a rather consistent failure on an UltraSPARC running
> Solaris 2.5.1.  I'm running omniORB 3.0.3 and registering servants
> with the Naming Service.  I don't have any trouble until the
> number of servants registering reaches around 48. They register
> themselves as they are invoked from a shell script.  The script
> sleeps 1 second between each invocation.

[...]
> open(/dev/zero): Too many open files
> libthread panic: alloc_chunk (PID: 21535 LWP 2)
> stacktrace:

Oh dear. It looks like what's going on is that a new connection comes
in, so omniORB tries to create a new thread. The Solaris libthread
tries to map /dev/zero to create something to do with the thread, and
fails because there are no file descriptors left. Rather than cleanly
reporting that thread creation failed, it aborts. If it had reported a
failure to omniORB, the connection would have been denied, and
omniNames would have continued OK.

I'm afraid it's a Solaris problem, rather than an omniORB one. One
option (if you're brave) is to try the omniORB 4 preview, since that
can transition to a thread pool model if there are more than a
specified number of connections. That limits the number of threads, so
it should avoid thread creation failures when the file descriptors run
out.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --