[omniORB] performance limits of omniNames (COMM_FAILURE)

[Sean Parker]

Hello - 

  I had some heavy-throughput issues also and I was getting
COMM_FAILURES due to connection limitations - I needed to
increase allowed files at the OS level, and I played with
the threading/connection options as well to get things to
flow. (Since my code is now at a "previous employer" I'm
afraid I can't just look up exactly my solutions)

  I recall it wasn't so much an OS-level thread allowance
as much as it was a file allowance. If on Linux, look into
sysctl issues for increasing the allowed files.

  I had great luck with throughput but didn't document
clearly the exact steps I needed to do to get it working
[to the point that I needed it to]. Once you iron this out,
can you provide feedback to authors so that this
information gets into the documentation? I think this is a
critical issue (the publication of resolving issues like
this) since:
  1) it communicates that omniORB is being used in
heavy-duty computing environments, 
  2) it communicates that the users and developer actually
know what they're doing (_I_ don't doubt it!) and,
  3) it helps others develop faster and with more
confidence in the design stage.

  Cheers
    Sean

--- Jaromír Talíř <jaromir.talir at nic.cz> wrote:

> Hello,
> 
>   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:
> 
> ---- begin of test.sh -----
> #!/bin/bash
> while /bin/true
> do
>     nameclt -ior corbaname::localhost resolve Name.Object
> > /dev/null
> done
> ---- end of test ----
>  
> when I run:
> > for i in `seq 1 300`; do { ./test.sh & }; done
> 
> After few minutes it start output:
> 
> Caught a TRANSIENT exception when trying to validate the
> type of the 
> NamingContext. Is the naming service running?
> Caught a TRANSIENT exception when trying to validate the
> type of the 
> NamingContext. Is the naming service running?
> ...
> 
> And after small time:
> 
> Unexpected CORBA COMM_FAILURE exception when trying to
> narrow the
> NamingContext.
> Unexpected CORBA COMM_FAILURE exception when trying to
> narrow the
> NamingContext.
> Unexpected CORBA COMM_FAILURE exception when trying to
> narrow the
> NamingContext.
> Unexpected CORBA COMM_FAILURE exception when trying to
> narrow the
> NamingContext.
> ...
> 
> What should it be? I tried to lookup omniORB thread
> options and I think
> defaults are fine. I expect that when no corba resources
> (threads?) are
> available, call is blocked waiting for
> resource(clientCallTimeOutPeriod
> is 0 by default), so there shouldn't be any failure (and
> only efficiancy
> will drop), is it true?
> 
> Regards
> 
> Jaromir Talir
> CZ.NIC
> > _______________________________________________
> 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