[omniORB] Making ORBs in CGI programs

[Duncan Grisby]

On Friday 25 January, Attila Pletyak wrote:

[...]
>   My question came up regarding the connection from the CGI programs to
> the router process. There will be tons of requests coming (50-100/sec)
> and with this 50-100 ORBs are gotten created making a local connection
> via the 127.0.0.1 shortcut. When the CGI process terminates the
> connection is thrown away. Can a Linux server bear such a (network)
> load?

I don't have any experience of this, but coincidentally one of my
office-mates has been trying something very similar, although not
(yet) using CORBA between the web server and the back-end server.
He says he'd be surprised if you can cope with so much load with CGI.
Opening and closing all those connections will take a lot of time. If
you have a powerful machine, you might get away with it. If you _can_
do it, we'd be interested to hear...

A better solution might be to use an Apache module, so it can keep the
connections open all the time.

>   I've read the "Local invocations" thread on this list which spoke
> about short-circuiting the connection from one process to the other on
> the same computer, using unix domain sockets. Will this feature be only
> in omniORB4 or are there any chance it will go into omniORB3 as well?

I think the thread about "local invocations" was talking about calls
to objects in the same process, avoiding the POA. That's of no use to
you here (and isn't particularly useful for most people).

omniORB 4 does have a Unix domain socket transport. That would
certainly help lower the load compared to using TCP loopback, but
opening and closing Unix sockets is still relatively heavy-weight. If
you find that your TCP version can almost keep up, but not quite,
using Unix sockets will solve that.

The Unix socket code in omniORB 4 can't be back-ported to omniORB 3,
since it uses a totally different transport framework. It would be
possible to make a Unix transport for omniORB 3, using its transport
framework, but we're certainly not going to do it.

> BTW is omniORB4 as stable as omniORB3 or there are a lot to do?

I don't think it's safe to claim it's _as_ stable as omniORB 3, since
there is quite a lot of new code. It is certainly very stable, though,
and people are using it in real deployed applications. The main thing
that is holding up the release is support for autoconf, and a few
things like cleaning up the interceptor interfaces. None of those
things affect the core functionality.

Cheers,

Duncan.

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