[omniORB] Interesting nameclt behavior

[Sai-Lai Lo]

>>>>> Gary D Duzan writes:

>    When attempting an unbind of an object in the name service, it
> complains of a COMM_FAILURE. The guilty call seems to be
> CosNaming::NamingContext::_narrow(obj), which is trying to verify that
> the the object (which it first resolves) is not a naming context.
> However, the bound object does not exist, so the _narrow() fails, and
> the exception is only caught in the one large try block around
> everything.  My feeling would be that if the _narrow() fails, than it
> should be (relatively) safe to try the unbind() anyway, and unless it
> does, nameclt can't be used to clean out dead IORs.
>    Has anyone else run into this?

Its a bug. You are right that unbind() can proceed safely even if _narrow
fails with a system exception. Here is a patch:

static
CORBA::Boolean
isNamingContext(CORBA::Object_ptr obj)
{
  try {
    CosNaming::NamingContext_var context
	 = CosNaming::NamingContext::_narrow(obj);
     if (!CORBA::is_nil(context)) {
        return 0;
     }
  }
  catch(...) {
     return 0;
  }
  return 1;  
}

-------- 
    //
    // unbind
    // -------
    //

    if (strcmp(command, "unbind") == 0) {

      CosNaming::Name name;
      GetName(argc, argv, n, 0, "", name);

      if (!advanced) {

	CORBA::Object_var obj = rootContext->resolve(name);

	if (isNamingContext(obj)) {
	  cerr << "Error: unbind: can't unbind a naming context.\n"
	       << "Use remove_context to remove an empty naming context."
	       << endl;
	  exit(1);
	}
      }

      rootContext->unbind(name);
      return 0;
    }
--------
There are several other places where the same change should apply. (Just
search for CosNaming::NamingContext::_narrow). I'll update the source in
the next snapshot.

Since 2.4.0, the behaviour of _narrow() has changed. This is described in
User guide section 6.3. Basically, the ORB works harder to find out the
type of an object it doesn't know about. This involves contacting the
object directly. The drawback of this approach is that you may get
COMM_FAILURE if the object is not there. I keep wondering whether raising
the system exception is creating more trouble than it is worth. An
alternative is to hide the system exception and returns a nil object
whenever the ORB cannot determine the type of the object.

Any comments?

Regards,

Sai-Lai

Note: if the stub for the object interface has been linked into the
executable, _narrow does not have to contact the remote object to work out
its type.