This section describes tips and techniques that you can implement to effectively use the CORBA APIs.
The APIs can be configured to use IOR files to route events to external applications. Your API System Administrator can tell you whether the APIs use IOR files in your environment.
IOR files are either created or overwritten if they already exist when the Oracle Communications MetaSolv Solution Application Server is brought up. IOR files contain a stringified object reference that encodes the IP address of the server that hosts the object and additional information specific to the ORB vendor that identifies the object reference.
A CORBA client can receive CORBA.INV_OBJREF or CORBA.OBJECT_NOT_EXIST exceptions when it attempts to use a stringified IOR object reference or any other remote object reference in any of the following cases:
The CORBA server that hosts the object has been brought down
The CORBA client has already called a destructor method in the IDL that destroys that object
The CORBA server times out
A typical situation where this might occur is where the server is re-configured to write IOR files to a new location, but the client is still reading old IOR files from the original location.
The most common cause of a CORBA.COMM_FAILURE exception is the remote ORB daemon being down, in addition to a server termination during a client operation. A newly-obtained remote reference is generally not validated during the string_to_object or narrow() operations. Instead, for the sake of efficiency, creation of a physical connection to the remote host is delayed until the first IDL operation is actually invoked. This is the point at which most remote exceptions occur. For Java ORBs, NullPointerExceptions during these initial connection operations can be the result of invalid mixed stub class and ORB class types or versions, as well as an attempt to marshal a structure (that is, to pass a parameter to a remote object) that contains a null string or other null element.
To use the API in a synchronous application such as a Web page, a multi-threaded client may use a mechanism (such as Java's Object.wait) in the calling method and Object.notify or Object.notifyAll in the notification object's result methods, which can be called by the ORB in a separate thread. When the result is returned, the calling thread wakes up, gets the data from the notification object, and continues processing. The notification object itself can be used as the monitor object.
When your application is developed in C++, the general principles remain the same. You must develop code to implement the callback object, and when linking object files to create an executable, must link in both the client and server libraries provided by the ORB vendor.Synchronization Primitives and C++
The C++ language does not provide synchronization primitives. If you use C++, you must use primitives supplied by the host operating system (for example, semaphores) to achieve the desired result.
If you are using C++ as your implementation language:
You must use a compiler version that supports the namespace feature.
You may encounter a problem while compiling the MetaSolv Solution IDL-generated source in C++ where CORBA primitive types are not found.
This can be traced to a problem with the IDL generator. C++ namespace resolution assumes that a CORBA::type, such as CORBA::char will be defined within the MetaSolv::CORBA namespace. The MetaSolv Solution API naming conventions and Java-based development do not permit this.
If you encounter this problem you must completely scope CORBA::types. For example, if the generated code is:
typedef CORBA::char null;
You should change the code to:
typedef ::CORBA::char null;
Review the documentation.
Confirm that you have used appropriate development techniques:
Design application and exception logging and stack tracing into your application. Make sure you have exception logging for all these cases:
CORBA exceptions
API exceptions
Logic exceptions
Control logging using .ini or command line parameters.
Dump structure traces before and after export or import.
Use existing logging capabilities:
API server logging
SQL logging
Console logging
CORBA logging
There is one log file per API server. For example, LSR.LOG.
Check the appropriate server's error log.
If required, set the GATEWAY.INI LoggingOn parameter to True.
If required, set the GATEWAY.INI TraceLevel parameter to the desired value:
0 = High level logging. Only error information.
1 = More detailed logging includes error information and some system information.
2 = Most detailed logging. Includes much more system information.
Note:
Only use high trace levels when debugging, because these options generate significant amounts of information.Log returned data.
If required, set GATEWAY.INI PrintExportObjects parameter to "True". This logs the values in objects in IDL structure format.
Note:
This option generates significant amounts of information.Log SQL statements.
If required, set the GATEWAY.INI SQLLogging parameter to "True".
Verify database related issues.
Note:
This option generates significant amounts of information.