13 Debugging

13.1 Tools and FAQ

Persons who use Orber for the first time may find it hard to tell what goes wrong when trying to setup communication between an Orber-ORB and ORB:s supplied by another vendor or another Orber-ORB. The purpose of this chapter is to inform about the most common mistakes and what tools one can use to overcome these problems.

Tools

To begin with, Orber can be configured to run in debug mode. There are four ways to set this parameter:

• erl -orber orber_debug_level 10 - can be added to a start-script.
• corba:orb_init([{orber_debug_level, 10}]) - this operation must be invoked before starting Orber.
• orber:configure(orber_debug_level, 10) - this operation can be invoked at any time.
• OrberWeb - via the Configuration menu one can easily change the configuration. For more information, see the OrberWeb chapter in this User's Guide.

When Orber runs i debug mode, printouts will be generated if anything abnormal occurs (not necessarily an error). An error message typically looks like:

=ERROR REPORT==== 29-Nov-2001::14:09:55 ===
=================== Orber =================
[410] corba:common_create(orber_test_server, [{pseudo,truce}]); 
not a boolean(truce).
===========================================

In the example above, we tried to create an object with an incorrect option (i.e. should have been {pseudo,true}).

If you are not able to solve the problem, you should include all generated reports when contacting support or using the erlang-questions mailing list.

It is easy to forget to, for example, set all fields in a struct, which one may not discover when developing an application using Orber. When using a typed language, such faults would cause a compile time error. To avoid these mistakes, Orber allows the user to activate automatic typechecking of all local invocations of CORBA Objects. For this feature to be really useful, the user must create test suites which cover as much as possible. For example, invoking an operation with invalid or incorrect arguments should also be tested. This option can be activated for one object or all object via:

• 'MyModuyle_MyInterface':oe_create(Env, [{local_typecheck, true}]) - This approach will only activate, or deactivate, typechecking for the returned instance. Naturally, this option can also be passed to oe_create_link/2, corba:create/4 and corba:create_link/4.
• erl -orber flags 2 - can be added to a start-script. All object invocations will be typechecked, unless overridden by the previous option.
• corba:orb_init([{flags, 16#0002}]) - this operation must be invoked before starting Orber. Behaves as the previous option.

If incorrect data is passed or returned, Orber uses the error_logger to generate logs, which can look like:

=ERROR REPORT==== 10-Jul-2002::12:36:09 ===
========= Orber Typecheck Request =========
Invoked......: MyModule_MyInterface:foo/1
Typecode.....: [{tk_enum,"IDL:MyModule/enumerant:1.0",
                         "enumerant",
                         ["one","two"]}]
Arguments....: [three]
Result.......: {'EXCEPTION',{'MARSHAL',[],102,'COMPLETED_NO'}}
===========================================

Note, that the arity is equivalent to the IDL-file. In the example above, an undefined enumerant was used. In most cases, it is useful to set the configuration parameter orber_debug_level 10 as well. Due to the extra overhead, this option MAY ONLY be used during testing and development. For more information, see also configuration settings.

It is also possible to trace all communication between an Orber-ORB and, for example, a Java-ORB, communicating via IIOP. All you need to do is to activate an interceptor. Normally, the users must implement the interceptor themselves, but for your convenience Orber includes three pre-compiled interceptors called orber_iiop_tracer, orber_iiop_tracer_silent and orber_iiop_tracer_stealth.

The orber_iiop_tracer and orber_iiop_tracer_silent interceptors uses the error_logger module to generate the logs. If the traffic is intense you probably want to write the reports to a log-file. This is done by, for example, invoking:

erl> error_logger:tty(false). 
erl> error_logger:logfile({open, "/tmp/IIOPTrace"}). 

The IIOPTrace file will contain, if you use the orber_iiop_tracer interceptor, reports which looks like:

=INFO REPORT==== 13-Jul-2005::18:22:39 ===
=============== new_out_connection =======
Node      : myNode@myHost
From      : 192.0.0.10:47987
To        : 192.0.0.20:4001
==========================================

=INFO REPORT==== 29-Nov-2001::15:26:28 ===
=============== out_request ==============
Connection: {"192.0.0.20",4001,"192.0.0.10",47987}
Operation : resolve
Parameters: [[{'CosNaming_NameComponent',
                "AIK","SwedishIcehockeyChampions"}]]
Context   : [{'IOP_ServiceContext',1,
               {'CONV_FRAME_CodeSetContext',65537,65801}}]
==========================================

The orber_iiop_tracer_silent will not log GIOP encoded data. To activate one the interceptors, you have two options:

• erl -orber interceptors "{native,[orber_iiop_tracer]}" - can be added to a start-script.
• corba:orb_init([{interceptors, {native, [orber_iiop_tracer_silent]}}]) - this operation must be invoked before starting Orber.

It is also possible to active and deactivate an interceptor during run-time, but this will only affect currently existing connections. For more information, consult Orber's Reference Manual regarding the operations orber:activate_audit_trail/0/1 and orber:activate_audit_trail/0/1.

FAQ

Q: When my client, typically written in C++ or Java, invoke narrow on an Orber object reference it fails?

A: You must register your application in the IFR by invoking oe_register(). If the object was created by a COS-application, you must run install (e.g. cosEventApp:install()).

A: Confirm, by consulting the IDL specifications, that the received object reference really inherit from the interface you are trying to narrow it to.

Q: I am trying to register my application in the IFR but it fails. Why?

A: If one, or more, interface in your IDL-specification inherits from other interface(s), you must register them before registering your application. Note, this also apply when you inherit interfaces supported by a COS-application. Hence, they must be installed prior to registration of your application.

Q: I have a Orber client and server residing on two different Orber instances but I only get the 'OBJECT_NOT_EXIST' exception, even though I am sure that the object is still alive?

A: If the two Orber-ORB's are not intended to be a part of multi-node ORB, make sure that the two Orber-ORB's have different domain names set (see configuration settings). The easiest way to confirm this is to invoke orber:info() on each node.

Q: When I'm trying to install and/or start Orber it fails?

A: Make sure that no other Orber-ORB is already running on the same node. If so, change the iiop_port configuration parameter (see configuration settings).

Q: My Orber server is invoked via IIOP but Orber cannot marshal the reply?

A: Consult your IDL file to confirm that your replies are of the correct type. If it is correct and the return type is, for example, a struct, make sure you have set every field in the struct. If you do not do that it will be set to the atom 'undefined', which most certainly is not correct.

A: Check that you handle inout and out parameters correctly (see the IDL specification). For example, a function which have one out-parameter and should return void, then your call-back module should return {reply, {ok, OutParam}, State}. Note, even though the return value is void (IDL) you must reply with ok.

Q: I cannot run Orber as a multi-node ORB?

A: Make sure that the Erlang distribution have been started for each node and the cookies are correct. For more information, consult the System Documentation