[omniORB] Scalability and maxStrands

[Sai-Lai Lo]

Andrew,

> I've seen too many situations where for one reason or another a server 
> needs to handle many, many more concurrent connections.  My two cents
> worth is that you up this a long way (like up to a couple hundred), and
> let the implementor worry about how to compensate for the load.
> 

The original posting was about how many concurrent connections a client is
allowed to make to a server. The server can always accept as many
concurrent connections as the OS allows.

omniORB2 clients only create more than one connections when there is more
than one thread making calls to the same remote address space
*concurrently*. The hard wired limit (5) is about how many of these
connections can be created.

By the way, connections idled for a application defined period would be
shutdown by the ORB. This can be initiated either on the server or the
client side.

If you want more details, have a look at the connection management chapter
in the omniORB2 user guide.

> This is part of why I asked the question on omniNames about having more 
> than one server registered.  A CORBA name server may not be the answer,
> but, for CORBA to be practical for serious, heavly-hit distributed
> applications that require any degree of failover, there needs to be some
> method of finding servers that returns either a list of servers
> (bindings) offering an object, or, selects one of the available servers
> randomly or by load.
 
There is another way of doing load-balancing in CORBA by using IIOP
location forwarding. Essentially, one designated a server as the first
point of contact for an object. The server does not actually implement the
object but acts as a redirector to the real server. When a request comes in
for the object, the server reply with a LOCATION_FORWARD message, pointing
the client to the real server. If needed, objects can be created/loaded on
demand among a pool of servers. After the first contact, the client will
call the real server directly. This mechanism is totally transparent to the
client application. If for some reason the real server goes down, the ORB
automatically retries the call with the first server. It may choose to
redirect the request to another server. We have been using this technique
successfully on a moderate scale system for some time now.

> The bank that I work for is pushing to move to CORBA (from DCE), but, as 
> much as DCE has flopped in many areas (like reliability and cost), CORBA
> is still drastically lacking in security and load handling.  I for one
> have not been following the OMG's latest moves, but, I hope these things
> are being considered, and, can be quickly implemented.  If so, CORBA will
> find its way to the mainstream in the banks, etc., much faster...

I hope you will find omniORB2 does not do too badly in terms of load
handling :-) As for security, this is admittedly a deficency. Things are
improving rapidly though.

Regards,

Sai-Lai


-- 
Dr. Sai-Lai Lo                          |       Research Scientist
                                        |
E-mail:         S.Lo@orl.co.uk          |       Olivetti & Oracle Research Lab
                                        |       24a Trumpington Street
Tel:            +44 223 343000          |       Cambridge CB2 1QA
Fax:            +44 223 313542          |       ENGLAND