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.
When connecting to the CORBA server from external systems, you may receive the following error message:
ERROR: Unable to Connect to Manager: org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to 10.196.7.146:2512 vmcid: 0x0 minor code: 0 completed: No ERROR: org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to <target ip address>:<target port> vmcid: 0x0 minor code: 0 completed: No
You may observe this issue if the CORBA server is hosted on a computer that has enabled two IP addresses; an internal IP address and an external IP address. If you install the MSS application on such a computer and enable the CORBA server, the internal IP address of the computer is copied in the IOR file when you create it. However, the internal IP address is not detected by the external systems trying to connect to the CORBA server on any given network. As a result, the external systems fail to successfully connect to the CORBA server and you receive the error message.
The internal and external IP addresses of a computer may differ, but the host name of the computer always remains constant. Therefore, for external systems to successfully connect to the CORBA server, you must specify the host name of the computer (instead of its IP address) in the IOR file.
To specify the host name of the computer in the IOR file, you must enable the jacorb.dns.enable property in both the orb.properties and jacorb.properties files, as follows.
jacorb.dns.enable=on
The default value of the jacorb.dns.enable property is off.
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 only one log file (jacORB.mss.log) for all the CORBA API servers.
Check the appropriate server's error log.
If required, set the LoggingOn parameter to true in the gateway.ini file.
If required, set the TraceLevel parameter in the gateway.ini file to the required 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 the PrintExportObjects parameter to true in the [Gateway] section in the gateway.ini file. 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 SQLLogging parameter to true in the [System] section in the gateway.ini file.
Verify database related issues.
Note:
This option generates significant amounts of information.