From 84adefa331c4159d432d22840663c38f155cd4c1 Mon Sep 17 00:00:00 2001 From: Erlang/OTP Date: Fri, 20 Nov 2009 14:54:40 +0000 Subject: The R13B03 release. --- lib/orber/doc/src/ch_debugging.xml | 209 +++++++++++++++++++++++++++++++++++++ 1 file changed, 209 insertions(+) create mode 100644 lib/orber/doc/src/ch_debugging.xml (limited to 'lib/orber/doc/src/ch_debugging.xml') diff --git a/lib/orber/doc/src/ch_debugging.xml b/lib/orber/doc/src/ch_debugging.xml new file mode 100644 index 0000000000..8c5685bc63 --- /dev/null +++ b/lib/orber/doc/src/ch_debugging.xml @@ -0,0 +1,209 @@ + + + + +
+ + 20012009 + Ericsson AB. All Rights Reserved. + + + The contents of this file are subject to the Erlang Public License, + Version 1.1, (the "License"); you may not use this file except in + compliance with the License. You should have received a copy of the + Erlang Public License along with this software. If not, it can be + retrieved online at http://www.erlang.org/. + + Software distributed under the License is distributed on an "AS IS" + basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See + the License for the specific language governing rights and limitations + under the License. + + + + Debugging + + + 2001-11-29 + + ch_debugging.xml +
+ +
+ 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.

+ +

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

+ +

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

+

+
+
+ + -- cgit v1.2.3