[omniORB] NS registration procedure question

[Sean Parker]

Well - it was an idiot issue with my build - of all things
- thus the unpredicatble behavior...

The trace levels help tremendously - thanks Duncan.

  God Bless
    Sean


--- Sean Parker <supinlick at yahoo.com> wrote:

> 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
> 
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
>
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
> 





God Bless 
    Sean Parker 





		
__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com