[omniORB] NS registration procedure question
Sean Parker
supinlick at yahoo.com
Sun Nov 20 21:18:09 GMT 2005
Hello -
I have several servers I connect to the Name Service.
Let's call them B and C which extend type A:
A
/ \
B C
Both impls of B and C are registered with the NS as impls
of B and C respectively. When in B, I get C's ref from the
NS, I have no problem narrowing to an 'A' but when I narrow
to a 'C' it gives a nil reference.
Since this had been working before, I'm more inclined to
think it's some kind of timing issue, for if I run NS, B, C
in certain orders, it seems to work, but most of the times
it doesn't work. I've no clue what I changed to keep it
from working. All references I register with NameService
can be used as an A, it's only when I narrow to the C that
there's a problem (so my registration and discovery is
working for the most part.)
I'm not asking for an answer to "what I did wrong to
break it" (thus people shouldn't need code) but more of a
theoretical discussion of any possible timing issues there
may be with registering/discovering a ref on the
NameService, how soon it can be used, C++-specific
declaration issues that may prevent client-side narrowing,
etc.) Since my reference registration and recognition
by-definition needs to be dynamic/asynchronous, I'm looking
for any inherent assumptions I may be making that are
invalid for the NameService/OmniNameService-implementation.
All of my servers behave the same - they come up and have
a list of named services they need. They continually peg
the NameService for these services, and once acquired a
callback passes the new ref and some action can be done
using the new ref. So as services come up and down (failure
recovery, host retasking, etc) the new references become
used and replace bad old refs. (BTW is this functionality
existant elswhere in omniORB, other ORB implementations, or
other RPC designs?)
Any insight would be appreciated, thanks and God Bless
Sean
God Bless
Sean Parker
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
More information about the omniORB-list
mailing list