[omniORB] performance limits of omniNames (COMM_FAILURE)

[Sean Parker]

Excellent points Duncan - 

  I'd suggest to people that if it's that much of a
big-deal to "pound omniNames beyond it's intended usage"
than the developers can take different approaches to the
problem:
  1) copy/rename omniNames itself, implementing a binary
tree name lookup if that will suit their needs;
  2) implement some sort of
redundancy/fail-over/load-balancing policy and have
multiple omniNames instances in there system.

  "2" brings up an interesting point - is there an OMG
standard, or other intended/built-in mechanism for handling
redundancy in CORBA?

  This issue seems rather basic, and something all systems
could use. It's not so much another "service" (like Time or
Trading) but is more involved in the nameService/initial
references realm of things.

  For example, I had designed such a scheme in the system
we had in my previous job, but never was able to implement
it. It basically provided for optional "redundancy
policies" for an application as client, and for the server.
For example a client would want the "SystemConfiguration"
(SC) reference, and if there werr two SC instances in the
system, a primary and a secondary on two servers, then a
reference manager in the application would know, based on
command-line policy declarations, whether to return the
"primary SC" or "secondary SC" (because they would have
been registered in the name service in a "primary" or
"secondary" name context), without the client code
designating/caring which was returned. Is there anything
else like that out there [in a standardized form]?

  This issue of nameService performance could be
solved/mitigated with such a mechanism, and then
scalability of any part of a CORBA system becomes almost a
mute point. Any comments?

  Cheers and God Bless
    Sean

--- Duncan Grisby <duncan at grisby.org> wrote:

> On Wednesday 7 November,
> =?UTF-8?Q?Jarom=C3=ADr_Tal=C3=AD=C5=99?= wrote:
> 
> >   we are using omniORB as a communication platform in
> just created
> > domain registry system for .cz TLD (about 350000
> domains, released as
> > open source on http://fred.nic.cz). Both python and c++
> parts are really
> > good. Many thanks to authors!
> >   
> >   But recently we had noticed on our production server
> (omniorb-4.0.6),
> > that in high load, omniNames started refuse to answer
> 'resolve' command
> > throwing CORBA/COMM_FAILURE. I managed to simulate this
> situation (hope
> > it's the same situation) with omniorb-4.1.0 by this
> simple script:
> 
> There are two scalability issues here. One is omniORB
> scalability. Its
> default policies are to use one thread per connection,
> and to keep idle
> connections open for quite a while. That means it can hit
> the OS's limit
> on open file descriptors or on running threads quite
> quickly. To help
> with that, you can set omniORB to thread pool mode (with
> quite a large
> pool size), and set the inConScanPeriod lower so idle
> connections are
> closed much more quickly. You can also make sure the
> process has as high
> a limit of file descriptors as the OS will allow.
> 
> The other issue is scalability of omniNames itself. It's
> a really simple
> thing that isn't intended to scale much. In particular,
> if you store a
> lot of names in a flat structure, it's dreadful because
> it uses a linear
> scan through linked lists of names when looking things
> up. If you need
> to store lots of name bindings, you should come up with
> some kind of
> hierarchy to avoid too much linear behaviour.
> 
> What are you using omniNames for?  It might well be
> better for you to
> use something else to store object references.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
>
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 





God Bless 
    Sean Parker 




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com