Re: problems with remote NameService calls

[Fabien Tassin <fta+orbit sofaraway org>]

More to this case.. including a solution.

According to Fabien Tassin:
> > 
> > Anyone to help me with that ?
> 
> I've identified my problem.
> 
> I traced it to ORBit_initial_references_by_user().
> When it receives a corbaloc from '-ORBInitRef NameService=' or -ORBNamingIOR,
> before calling ORBit_set_initial_reference(), it should check that
> "NameService" _is_a() IDL:omg.org/CosNaming/NamingContext".
> The answer would have been (in my case) a location forward
> to a new Object key. Another _is_a() on that new key would be ok.
> Then CosNaming_NamingContext_list() would work as expected.
> 
> There's a FIXME in orb-core/corba-orb.c ORBit_initial_references_by_user()
> that is related to that. The second call of ORBit_set_initial_reference()
> in ORBit_initial_references_by_user() needs the same FIXME.
> 
> The loop I'm experiencing is just that. CosNaming_NamingContext_list()
> receives the location forward to that new key but does not handle
> it properly and loops with the initial key (NameService) instead
> of using the new one. IMHO, that's a bug too.

The loop is in ORBit_small_invoke_stub().
The 1st orbit_small_demarshal() call sets obj->forward_locations
then returns MARSHAL_RETRY which causes the 1st iteration. Fine.
Then, obj->forward_locations seems to be completely ignored producing
an infinite loop. For this to work, ORBit_object_get_connection()
must be called at each retry.. I've tried with the 'retry_request:'
label a few lines above to include ORBit_object_get_connection() but
it doesn't help.. the reason is there:

GIOPConnection *
ORBit_object_get_connection (CORBA_Object obj)
{
        /* .. declarations .. */
	if (obj->connection) {
		if (ORBit_try_connection_T (obj)) {
			cnx = obj->connection;
			giop_connection_ref (cnx);
			OBJECT_UNLOCK (obj);
			return cnx;
		} else {
			OBJECT_UNLOCK (obj);
			return NULL;
		}
	}
	g_assert (obj->connection == NULL);
	if (!obj->forward_locations) {
		plist = obj->profile_list;
		objkey = obj->object_key;
	} else {
		plist = obj->forward_locations;
		objkey = IOP_profiles_sync_objkey (plist);
	}
        /* .... */
}

obj->forward_locations is never used as on the 2nd call, we already
have a connection.
I've hacked the code to do the proper actions but it fails later
as the 2nd IOP_profiles_sync_objkey() completly looses track of
the object (by design). Once again, I've patched it and I'm finally
able to obtain the expected answer from CosNaming_NamingContext_list().

Problem: the patch is dirty and may have counter effects on other
parts of the code :( Anyway, this is a serious bug and the two
_is_a() calls I've mentionned are also more than welcome.
Do you wish me to post a patch knowing that I'm unable to test
it in all situations ?

/Fabien

> I've just read the implementation of CORBA_Object_is_a() and I'm
> not sure that function does what I need, ie send GIOP _is_a() requests
> and handle location forwards properly (if any).
> 
> Could someone help me from here ?
> 
> /Fabien
> 
> > According to Fabien Tassin:
> > > Date: Mon, 31 May 2004 16:25:21 +0200
> > > 
> > > Hi,
> > > 
> > > I have an Orbit2 client talking to a remote non-Orbit server.
> > > It works well when used with a (fixed) IOR read with
> > > client_import_service_from_stream().
> > > I now wish to use the NameService on the remote ORB to get the IOR
> > > dynamically.. but it doesn't work.
> > > 
> > > Here is a minimalistic piece of code.
> > > 
> > > ==
> > >   /* ... */
> > >   orb = CORBA_ORB_init(&argc, argv, "orbit-local-orb", ev);
> > >   abort_if_exception(ev, "CORBA_ORB_init() failed");
> > > 
> > >   nameservice = CORBA_ORB_resolve_initial_references(orb, "NameService", ev);
> > >   abort_if_exception(ev, "resolve_initial_references(NameService) failed");
> > > 
> > >   context = (CosNaming_NamingContext) nameservice;
> > >   g_assert(!CORBA_Object_is_nil(context, ev));
> > > 
> > >   CosNaming_NamingContext_list(context, 0, &bl, &bi, ev);
> > >   abort_if_exception(ev, "list() failed");
> > >   g_assert(!CORBA_Object_is_nil(bi, ev));
> > >   /* ... */
> > > ==
> > > 
> > > I invoke this using -ORBInitRef NameService=corbaloc::remote:port/NameService
> > > It goes into an infinite loop in CosNaming_NamingContext_list().
> > > 
> > > ethereal+strace show that the CORBA_ORB_resolve_initial_references() call is
> > > not made against the remote ORB but against the local one (from my
> > > Gnome2 desktop, reading /tmp/orbit-myuser).
> > > CosNaming_NamingContext_list() talks to the remote ORB but loops..
> > > [ Request (two-way): list -> Reply: Location Forward ]
> > > I assume this is because 'nameservice' is wrong.
> > > 
> > > I'm quite sure it is a problem with my client code (or Orbit2)
> > > as 'nameclt' from omniorb4 works perfectly.
> > > (nameclt -ORBInitRef NameService=corbaloc::remote:port/NameService list)
> > > 
> > > Maybe I missed something or did something wrong..
> > > 
> > > $ orbit2-config --version
> > > ORBit2 2.10.2
> > > 
> > > Thoughts ?
> > > 
> > > /Fabien
> > > _______________________________________________
> > > orbit-list mailing list
> > > orbit-list gnome org
> > > http://mail.gnome.org/mailman/listinfo/orbit-list
> > _______________________________________________
> > orbit-list mailing list
> > orbit-list gnome org
> > http://mail.gnome.org/mailman/listinfo/orbit-list