## 14 Debugging

### 14.1 Tools and FAQ

Persons who use Orber for the first time may find it hard to tell what goes wrong when tryong 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.

#### 14.1.1 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, se 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 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 a pre-compiled interceptor called `orber_iiop_tracer`.

| Logging all traffic is expensive. Hence, only use the supplied interceptor during test and development.

The `orber_iiop_tracer` interceptor 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 reports which looks like:

    =INFO REPORT==== 29-Nov-2001::15:26:28 ===
    =============== new_out_connection =======
    Node      : 'myNode@myHost'
    To Host   : "123.456.789.012"
    To Port   : 2000
    ==========================================

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

To activate the `orber_iiop_tracer` interceptor, 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]}}]) - this operation must be invoked before starting Orber.

#### 14.1.2 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 exapmle, 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.

Copyright © 1991-2002 Ericsson Utvecklings AB