[omniORB] NS registration procedure question

[Sean Parker]

Duncan - 
  Thanks for the info.
  I looked in the doc and saw info regarding an example
using A,B,C,D and attempting to approach this issue but it
wasn't particularly clear, especially when indicating the
exmaple code line numbers.(this is an OmniOBR version I
downloaded last spring)
  Either way, it suggested possible link issues, so I
looked into that and that didn't help.
  I've repeatedly verified that my IDL and impl codes are
the same, in terms of extending A, for example. What's most
disturbing, is that both B and C impls use the same
reference-manager code to acquire NS refs and narrow to A
(which always succeeds) and for example whenever B narrows
C's ref to C that ALWAYS works, and when C narrow's B's ref
to B, that works only ~1% of the time. Thus my growing
anxiety... it works so rarely I can't trace the exact steps
I took (ie. server start-up order, etc) to get it to work. 

  I have gone into the omniObjRef.cc and added prints to
see what's going on, and it sure is crapping-out on
thinking my B isn't a B, returning nils. Can you suggest an
area of code I can add prints-to to textually see what the
actual repoid is in the reference coming from the
NS->resolve call, in the client?

  Anyway, I'm sure it's my fault, and I'm not blaming the
NS, simply implying the robustness of my code, that I'm not
"doing anything fancy", and the simplicity of what I want
to do.

  I'll try the traces you suggested.

  Cheers, and God Bless
    Sean


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

> On Sunday 20 November, Sean Parker wrote:
> 
> >   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. 
> 
> The naming service is not involved in type checking and
> narrowing.
> Whatever the problem is, it has nothing to do with the
> naming service.
> All the naming service does is map names to object
> references.
> 
> The types of interfaces are named with "repository ids".
> For your
> interface C, the repository id is IDL:C:1.0.
> 
> Object references embed a repository id, naming an
> interface they
> support. Normally, it is the most-derived interface. So,
> when your C
> object reference is registered in the naming service, it
> would normally
> have the repository id IDL:C:1.0 embedded in it.
> 
> Now, when you come to narrow the object reference you get
> from the
> naming service, the target type (IDL:C:1.0) is compared
> with what's
> inside the object reference. If they match, the narrow
> succeeds
> immediately. I would expect that to happen in your case.
> 
> If the types do not match, but the ORB knows the types
> are compatible,
> as would be the case of narrowing a C reference to A,
> again the narrow
> will succeed.
> 
> If the ORB does not know whether the types match, it
> performs a remote
> call to the object to ask it, calling its _is_a() method.
> The remote
> object replies true or false, and the narrow therefore
> succeeds or
> fails, depending on whether the object really does
> support the interface
> or not.
> 
> Notice that the naming service is not involved in any of
> this.
> 
> So, to understand why your narrows are failing, we need
> to know what
> repository ids are in the object references, and why the
> repository ids
> are not matching. Run your code with command line
> arguments of
> -ORBtraceLevel 25 -ORBtraceInvocations 1. That will print
> lots of
> debugging, including information about the types of
> object references.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
> 





God Bless 
    Sean Parker 





	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com