Why does osfind (location service) throw the exception ObjLocation::Fail reason 4?

Question:

Why does osfind (or the location service) throw an exception:

EXCEPTION ObjLocation::Fail {
        reason: 4
}
 

Why does osfind continues to show osagent that has terminated and how can
can a user force the osagents to clean up their internal dictionaries to
lose awareness of the terminated osagent?

Resolution One:

This resolution applies when one of the osagents listed in the output from osfind is not running (as confirmed by the ps command on unix or the task manager on Windows NT.)

If there are two agents (listening on the same UDP port on two different machines on the same subnet) the following sequence occurs:

Let us call the agents Agent 1 and Agent 2. Agent 1 is already up and running first, and then Agent 2 starts up. When Agent2 starts up it UDP broadcasts and notifies Agent1 of its existence. Agent1 records this information internally. As part of this protocol, Agent2 also sends an "Are You Alive" message to Agent1. Agent1 responds to Agent2, Agent2 now records the existence of Agent1.

When Agent2 goes down gracefully, Agent1 deletes the existence of Agent2 internally and continues.

When Agent2 goes down abnormally (such as killing using the Task Manager on Windows), Agent1 never knows about it until a client asks for an object reference that is not in the dictionary of Agent1 and Agent 1 forwards the request to Agent2 (which does not exist, forcing Agent1 to clean up). Until this point, osfind would still show two agents listed and will catch ObjLocation::Fail exceptions.

There is no other periodic heartbeat message between the agents and hence no chance for cleanup.

There is a simple trick to force osagents to lose awareness of other osagents that have terminated abruptly.  If a client issues a request, and the request cannot be satisfied by the osagent, it will forward the request
to the osagents that it currently knows about.  If one of those osagents does not respond to the request then it will attempt to verify the existence of the other osagent.  If it does not successfully confirm the existence of
the other osagent then it removes it from its list.  A simple client utility can be written (shown below) to force the cleanup described above.

The IDL:

interface Clean {
};

The Code:

1. include
   
2. include "clean_c.hh"

int main(int argc, char* const* argv) {
  try {

    CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    Clean_var dontcare = Clean::_bind();

    cout << "A Clean interface was actually located! "
         << "This command was probably ineffective"
         << endl;

  } catch(...) {
    cout << "A Clean interface was not located! "
         << "This command was probably effective"
         << endl;
    return(0);
  }
  return(1);
}

Resolution 2:

This resolution applies when one of the osagents listed in the output from osfind is known to be  running (as confirmed by the ps command on unix or the task manager on Windows NT.)

VisiBroker clients contact the osagent on a "client handler address" that it obtains from the osagent.  This exchange is transparent to the application.  The client handler address is comprised of a host IP address and a port number assigned by the osagent.

It is possible in a multi-homed machine for the osagent to provide a client handler address on an interface that cannot be reached by the client.  In this case the use of the localaddr file may be required to configure the osagent in such a way that it can be contacted on the client handler port by the client.

See VisiBroker for C++ Programmer's Guide, Chapter 10, The Smart Agent Architecture, Section "Working with Multi-homed Hosts".

See Installation and Administration Guide, Chapter 4, Starting Runtime Support Services, Section "Running the Smart Agent on Multi-homed Hosts"
 

Article originally contributed by

Tags: CORBA Services CORBA