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 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
andcorba: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 usefull 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 two pre-compiled interceptors called
orber_iiop_tracer
andorber_iiop_tracer_silent
.
Logging all traffic is expensive. Hence, only use the supplied interceptors during test and development.
The
orber_iiop_tracer
andorber_iiop_tracer_silent
interceptors uses theerror_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 theorber_iiop_tracer
interceptor, 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}}] ==========================================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.
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
andout
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 theSytem Documentation