FAQ

 static Server_Strategy_Factory "-ORBConcurrency thread-per-connection"
static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive
                               -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1"

static Resource_Factory "-ORBFlushingStrategy blocking" 

  EndpointPolicy::EndpointList list;
  list.length (1);
  list[0] = new IIOPEndpointValue_i("localhost", endpoint_port);

  CORBA::Any policy_value;
  policy_value <<= list;

  CORBA::PolicyList policies;
  policies.length (1);
  policies[0] = orb->create_policy (EndpointPolicy::ENDPOINT_POLICY_TYPE,
                                    policy_value);

  PortableServer::POAManagerFactory_var poa_manager_factory;
  poa_manager_factory = root_poa->the_POAManagerFactory ();

  PortableServer::POAManager_var good_pm;
  good_pm = poa_manager_factory->create_POAManager ("goodPOAManager",
                                                     policies);

  policies.length(0);
  PortableServer::POA_var good_poa =
    root_poa->create_POA ("goodPOA",
                          good_pm.in (),
                          policies);
  good_pm->activate ();

General/Miscellaneous Questions ⊲

• How can I get TAO to use a transport protocol other than TCP/IP? ⊲

  TAO includes a "pluggable" transport protocol framework that allows the ORB to be configured to work over transports other than TCP/IP. In fact, the standard Internet Inter-ORB Protocol (IIOP) is implemented in TAO as a pluggable transport protocol that is based on TCP/IP. Besides IIOP, TAO comes with several alternate transport protocol implementations, including:

  • Unix Inter-ORB Protocol (UIOP), which is based on Unix Domain Sockets (or local IPC)
  • Shared Memory Inter-ORB Protocol (SHMIOP), which uses shared memory as a transport.
  • Datagram Inter-ORB Protocol (DIOP), which uses UDP for efficient message transfer in limited circumstances.
  • Secure Sockets Layer Inter-ORB Protocol (SSLIOP), which is based on SSL.
  • Multicast Inter-ORB Protocol (MIOP), implemented atop Unreliable IP Multicast (UIPMC).
  • Hypertext Inter-ORB Protocol (HTIOP), which uses HTTP tunneling.
  • Stream Control Transmission Protocol Inter-ORB Protocol (SCIOP), which is based on SCTP (IETF RFC 2960).

  Currently, the UIOP, SHMIOP, DIOP, and SCIOP implementations are all found in $TAO_ROOT/tao/Strategies/ and the TAO_Strategies library. SSLIOP is implemented in the TAO_SSLIOP library in $TAO_ROOT/orbsvcs/orbsvcs/SSLIOP/, MIOP/UIPMC in the TAO_PortableGroup library in $TAO_ROOT/orbsvcs/orbsvcs/PortableGroup/, and HTIOP in the TAO_HTIOP library in $TAO_ROOT/orbsvcs/orbsvcs/HTIOP/.

  The use of the underlying transport protocol is completely transparent to the application. In fact, the ORB can actually be configured to use more than one transport protocol simultaneously.

  If one of the above built-in transport protocols does not meet your needs, you may need to implement one yourself. If done correctly, it should require no changes to the TAO core. Use one of the existing pluggable transport protocol implementations as guidance.

  Using and developing pluggable protocols is documented in detail in the TAO Developer's Guide.

• Which thread does TAO use to dispatch a request? ⊲

  The answer to this depends on a number of conditions:

  • If the client is collocated with the servant and collocation is enabled, then the request is serviced on the client's thread. Collocation can be disabled via the option: -ORBCollocation no
    
  • If the client is not in the same process as the servant (or collocation is disabled), then the concurrency strategy of the servant's ORB determines the servicing thread. By default, this is the same thread where orb->run() or orb->perform_work() is called. You can also specify a thread-per-connection model via the -ORBConcurrency option and a threadpool model by using the thread pool reactor.

  See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/Options.html?view=co for more details on these options.

  See http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col18.pdf for a discussion of TAO's collocation optimizations.
  

• How can I detect when a connection between a client and server is broken? ⊲

  (Paraphrased from e-mail by Carlos O'Ryan coryan@uci.edu)

  You cannot directly detect when this happens. You could write a pluggable protocol that informs your application when a connection dies, but that's about it.

  Typically behind this question is the issue: how can I detect if my client died. Using connections for that is a very bad idea: the client or server ORBs may close the connection just because it is idle for too long or there may not be a physical connection between two ORBs (they may be collocated or using shared memory to communicate). There can also be multiple connections between a given client-server pair. In CORBA, connections are hidden, and can come and go as needed. Trying to rely on them to establish if the client is still there does not work.

  In general you are better off using some application-level session object that gets destroyed by the client when it terminates gracefully, and that gets destroyed by an Evictor if it has been idle or unable to contact the client for too long.
  

• What are these CORBA::Environment parameters? Why do I get errors about pure virtual functions? ⊲

  The CORBA::Environment parameters are part of the alternate exception mapping defined by the OMG's IDL to C++ language mapping specification. Normally, CORBA exceptions are mapped to C++ exceptions. The mapping also allows CORBA to be used when C++ exceptions are unavailable or undesirable by passing exception information via an extra parameter of type CORBA::Environment. TAO versions up to 1.5.1 support both mappings and you can build ACE/TAO to support either mapping by passing exceptions=0 or exceptions=1 to GNU make or by defining the macro ACE_HAS_EXCEPTIONS.

  If you build TAO to use native C++ exceptions, the IDL compiler, by default, does not include the CORBA::Environment parameters. If you build with the alternate mapping, the IDL compiler includes the CORBA::Environment parameter by default. You can explicitly tell the IDL compiler what to do with the -Ge option (-Ge 1 includes the extra parameter, -Ge 0 omits it). You need to generate the skeleton classes in a manner that is compatible with your servant classes or you will receive compiler errors about abstract classes or pure virtual functions.

  For more information about Exceptions and TAO, see the Error Handling chapter of the TAO Developer's Guide.
  

• What is involved with using std library (inc stl) with ACE/TAO? ⊲

  There are several conditional directives that are relevant:
  

  • ACE_HAS_STANDARD_CPP_LIBRARY -- Causes ACE to #include the standard libraries where appropriate instead of older style runtime libraries, or defining its own equivalent. (ie <cstdio> instead of <stdio.h> or <memory> instead of creating its own auto_ptr)
    
  • ACE_USES_STD_NAMESPACE_FOR_STDCPP_LIB -- This causes ACE to define "using std::xxx" for all the std classes it uses. I've never messed with this one, so I'm not sure of all the ramifications. I notice that it is defined by default for most (all?) windows compilers.
    
  • ACE_HAS_STDCPP_STL_INCLUDES -- This seems to be used only in ace/IOStream.h. It causes ACE to use <string> instead of <String.h>. It's not defined for VC++, but is for some other win32 compilers. I've never used this one either.

  In practice, I typically define ACE_HAS_STANDARD_CPP_LIBRARY, and use stl and other std objects in my code. You can still use std library functions and objects without defining ACE_HAS_STANDARD_CPP_LIBRARY, but it can be a hassle because of duplicate definitions. (e.g. std::cout & cout are different, so you have to explicitly use std:: most places, and you can't use them interchangeably)
  In practice it is fairly common to use ACE_HAS_STANDARD_CPP_LIBRARY. I always use this, and prefer the standard library to ACE where there is overlap. (ie std::map or hash_map over ACE_Hash_Map_Manager_Ex) Of course this can be a portability issue.
  

• Why does ORB_init change the order of the command line arguments if we pass argv to ORB_init(argc, argv)? ⊲

  CORBA::ORB_init() is supposed to remove all "-ORB" options it recognizes. One way of doing that logically and efficiently is to put all of those recognized arguments at the end of the argument vector and adjust the argument count (argc) accordingly.

  You are only supposed to use the first "argc" number of arguments after call CORBA::ORB_init(). In your case, you had:

    argc = 3    and argv = { "ex", "-ORBDebugLevel", "5" }
  

  After calling CORBA::ORB_init() you have:

    argc = 1    and argv = { "ex", "5", "-ORBDebugLevel" }
  

  This means that you should only be using first argument from the argument vector.
  
  If you need to maintain the order of the original argument vector for later use, then you have to make a copy before calling CORBA::ORB_init().

• Why don't signals work with the ORB's reactor? ⊲

  Signals and the ORB reactor:
  

  By default ACE uses the ACE_Select reactor, which works with signals. TAO defaults to use the thread pool (TP) reactor, which does not currently work with signals. See DOC Bug 1031:
  
  http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1031

  The call ACE_Reactor::instance() returns an ACE_Select_Reactor. The call TAO_ORB_Core_instance()->reactor() returns an ACE_TP_Reactor.

  Another possible approach for handling signals in a TAO application that uses the default TP reactor would be to spawn a separate thread and use ACE_OS::sigwait() to handle the signals.

• What is TransportCurrent library used for ? ⊲

  It provides an implementation of an interface(Transport::Current) for obtaining common transport information and an implementation of IIOP specific interface (Transport::IIOP::Current) for obtaining IIOP specific transport information. On the other hand it also is a framework for implementing transport-specific plug-ins (for querying specific transport, other than IIOP).

  Please see $TAO_ROOT/docs/transport_current/index.html for description of the Transport Current feature.

• How can my TAO application obtain endpoint information (e.g., IP address and port for IIOP) of the client during a request invocation? ⊲

  The TransportCurrent(see LINK:163:) library provides the IIOP specific interface (TAO::Transport::IIOP::Current) and implementation. The TAO::Transport::IIOP::Current interface provides access to the information of the local and remote endpoints.

  Here is an example to obtain endpoint information via TAO::Transport::IIOP::Current interface.

    
    // Get the IIOP Current object.
    CORBA::Object_var tcobject =
      orb->resolve_initial_references (ACE_TEXT_ALWAYS_CHAR
  ("TAO::Transport::IIOP::Current"));
  
    Transport::IIOP::Current_var tc =
      Transport::IIOP::Current::_narrow (tcobject.in ());
  
    if (CORBA::is_nil (tc.in ()))
      {
        ACE_ERROR ((LM_ERROR,
                    ACE_TEXT ("Tester (%P|%t) ERROR: Could not resolve ")
                    ACE_TEXT ("TAO::Transport::IIOP::Current object.\n")));
  
        throw CORBA::INTERNAL ();
      }
  
    // Access the host and the port of the remote endpoint.
    ::CORBA::String_var rhost (tc->remote_host ());
    ::CORBA::Long rport = tc->remote_port ();
    
    // Access the host and the port of the local endpoint.
    ::CORBA::String_var lhost (tc->local_host ());
    ::CORBA::Long lport = tc->local_port ();
    

  Note the transport information is only available on server-side at interception points or inside a servant up-call. Specifically, the code above must be called within interceptor hooks(e.g. receive_request_service_contexts(), receive_request(), send_reply() and etc.) or inside a servant implementation method.

  To use the Transport Current features, the TransportCurrent library must be loaded via Service Configurator, or be statically linked . Here is an example of the Service Configuration file.

  
    dynamic TAO_Transport_Current_Loader Service_Object *
          TAO_TC:_make_TAO_Transport_Current_Loader() ""
  
  

  (Note that this has been split across lines for the purpose of display on this web page. The actual service configuration file should have the above contents all on one line.)

  One could achieve the same, by using -ORBSvcConfDirective with the above as a parameter.

• How can my TAO client obtain information about the endpoint (e.g., IP address and port for IIOP) it is using to send a request? ⊲

  The TAO::Transport::IIOP::Current interface can be used to obtain information about the local and remote endpoints. Please see example code in LINK:164:. Similar code can be used by the client to obtain information about the endpoint used to send a request. Note since the transport information is only available on client side at interceptor points (within send_request, send_poll(), receive_reply(), receive_exception() and receive_other ()), TAO must be built with support for interceptors if the client side needs Transport::Current functionality.

• How can my TAO clients and servers communicate when the network goes down? ⊲

  Assuming that the clients and servers are local to one machine, it is possible by using "localhost". For instance, you could have a Name Service running that is listening on the ethernet adapter and localhost:

    Naming_Service -ORBListenEndpoints "iiop://hostname:11223;iiop://localhost:11223"
  

  If the network for "hostname" goes down, this Name Service could still be accessed by a server running locally using the following:

    server -ORBInitRef NameService=corbaloc:iiop:hostname:11223,iiop:localhost:11223/NameService
  

  Regardless of the state of the network on which "hostname" is registered, the server will be able to communicate with the Name Service due to the localhost endpoint.

• I am using UIOP and/or SHMIOP and I see artifacts left in the filesystem after a server crash. How do I deal with that? ⊲

  UIOP uses filesystem tokens to identify endpoints. By default these are named /tmp/TAOsomething, but they can also be whatever you specify. When your server ORB is shut down, it will clean up the token associated with any UIOP or SHMIOP transport. However on a crash, the endpoint token remains in the filesystem, and will cause a re-run of the server to fail. SHMIOP uses a filesystem entry per connection which serves as the shared memory identifier.

  If you are using a well known UIOP endpoint, such as /tmp/my_uiop_endpoint, you can simply delete the named file in your server startup, before invoking CORBA::ORB_init(). This is easily done using ACE_OS::unlink("/tmp/my_uiop_endpoint"). When using generated endpoints, the files to clean up are anmed /tmp/TAO*. As long as you have no other servers running with UIOP, then just delete all instances of /tmp/TAO*. Otherwise you can use the catior (or tao_catior if catior isn't found) to determine which of the /tmp/TAO* rendesvous points are still active.

  Identifying leftovers from a crashed SHMIOP session is a little more difficult. The default name for the identifier is /tmp/MEM_Acceptor_port_uniqueid where port is the port number used for the connection establishment and the uniqueid is something that futher distinguishes a specific instance of the connection. For example /tmp/MEM_Acceptor_55957_0x65754014330. The SHMIOP Factory takes a "-MMAPFilePrefix=..." option to override the use of /tmp/MEM_Acceptor_. As with the UIOP endpoints, you can simply delete these files from your filesystem after a crash. Also like UIOP, these temporary files are cleaned up when the connection is successfully closed.

Errors, and possible solutions ⊲

• Why do I experience a run-time link error, even though my path and environment variables are set correctly and I have a fresh build tree? ⊲

  You may have an older version of one of the ACE, TAO, or CIAO libraries somewhere in your library search path (e.g., PATH on Windows, LD_LIBRARY_PATH on Linux) that you don't know about, even though you have only one build tree of ACE+TAO+CIAO. For example, the CoSMIC tool chain installer ships with the ACE libraries and installs them on your system. The same is true of OCI's TAO distribution CDs.

  If you do have an out-dated version of one of the ACE, TAO, or CIAO libraries (e.g., ACE.dll), and its path appears in the library search path before $ACE_ROOT/lib from your build tree, you will have run-time link errors. The run-time linker tries to link your program against the first occurrence of the library that it finds in the library search path.

  You can confirm that this is the problem you are having by moving the problematic library in your build tree to a backup file and re-running your application. If you still experience the run-time link error, then you probably have another (stale) version of the problematic library on your system. (The ldd command on Linux and Unix can be very helpful in tracking down where the out-dated library is located.) To correct the problem, ensure that $ACE_ROOT/lib comes first in the library search path. On Windows, you will need to restart your terminal windows and development environment.

  Thanks to Stoyan Paunov for contributing this question and answer.

• My server IOR contains the address 127.0.0.1 and my client, running on a different machine, can't connect. What do I do? ⊲

  When determining the endpoint for a server, TAO chooses an interface from the interfaces available to the system and encodes its address within the IOR. If TAO chooses 127.0.0.1 (the local loop back) as the endpoint address, then it could not find any other suitable interfaces. Since this address is only visible to local machine, no other machine will be able to connect to the local machine through that address.
  If there are dynamic interfaces that are available to the system, you may need to explicitly specify that TAO should use that interface with the -ORBListenEndpoints command line option:
  

    -ORBListenEndpoints iiop://< hostname or ip address >:< port >
  

  
  

• Why I am getting errors when I try to initialize the first ACE object in an application? ⊲

  The short answer is that you probably need to call ACE::init() before initializing or using any ACE/TAO objects. You should also be sure to call ACE::fini() at the end of your application's use of ACE.

  When you include ACE/TAO headers from the file containing the main() function, the ACE::init() function is called automatically for you at the start of main(). ACE::init() initializes the ACE Object Manager, and must be called before initializing or using any ACE/TAO objects. When you only use ACE/TAO from libraries that are dynamically linked, you may need to explicitly call ACE::init() beforehand. Also, you will need to call ACE::fini() to close down the ACE Object Manager at the end of your application's use of ACE/TAO (e.g., at an exit point from the code in your library).

• Why is my application leaking memory when I use local objects? ⊲

  It is likely that your objects are using reference counting to manage their life cycle. The CORBA::LocalObject class provides an empty implementation of the _add_ref() and _remove_ref() methods. However, the TAO_Local_RefCounted_Object implements real reference counting through these methods.

  The solution to your memory leak may be as simple as inheriting from TAO_Local_RefCounted_Object instead of CORBA::LocalObject.

• Why does my application fail when the client and server are on different hosts? ⊲

  When an application works with the client and server on the same host, but fails when they are on different hosts, the usual culprit is some sort of naming problem between the hosts. One simple way to test this is to use the ping command to attempt to ping each host from the other (using the host name). You need to ping in both directions as TAO will require both paths.

  Another way to test this (and even make it work) is to tell TAO to use decimal addresses (i.e. 128.252.120.1) instead of host names. You can do this by passing -ORBDottedDecimalAddresses 1 via argv[] to CORBA::ORB_init() in each process of your application. Note that you need to do this for every CORBA server in your system. Because many client applications are also CORBA servers, it is best to use this option for all processes. Assuming your code passes command line options to CORBA::ORB_init(), you can do this from the command line:
  

    server -ORBDottedDecimalAddresses 1
    client -ORBDottedDecimalAddresses 1
  

  Even if this works, you still probably want to get your system administrators to fix the naming problems. If you want to always force use of decimal addresses add the following to your $ACE_ROOT/ace/config.h:

    #define TAO_USE_DOTTED_DECIMAL_ADDRESSES 1
  

  Note: In recent versions of TAO, on Windows, the default is to use dotted decimal addresses rather than hostnames.

  You may also run into the problem described in this question if your server happens to be listening on the address associated with the loopback device. The IP address for this "host" is 127.0.0.1 and often (especially on Linux-based hosts), the hostname is set to localhost.localdomain. Thus, when your client tries to resolve the hostname, it resolves it correctly but connects to itself rather than the host on which the server is actually running.

  Use catior (in $TAO_ROOT/utils/catior) to "peek inside" your TAO-generated IORs; if you see localhost.localdomain (or something similar) in the output, then you might have this problem! Use the -ORBListenEndpoints option (also called the -ORBEndpoint option) to specify the hostname on which the server should listen for requests (and, thus, the hostname that it encodes in the IORs it generates).

  The -ORBListenEndpoints option takes many arguments and modifiers. See https://svn.dre.vanderbilt.edu/viewvc/Middleware/trunk/TAO/docs/ORBEndpoint.html?view=co and the TAO Developer's Guide for more details on the the -ORBListenEndpoints option.

  Thanks to Tim Fry <tfry at imoney dot com> for posting to the tao-users mailing list the raw material from which this entry was created.

• Why does my multithreaded server deadlock when I make an invocation from an event handler registered with the ORB's reactor? ⊲

  (Expanded question): I am running a server with a few threads in a thread pool. I have also registered an event handler with the ORB's Reactor from which I am making remote invocations. My server is deadlocking. Note: I am using the default configuration (i.e., default concurrency strategy, wait strategy, flushing strategy, etc.)

  (Answer): By default, the ORB uses a Leader Follower (LF) for receiving requests and processing replies from remote targets. It uses a simple protocol that keeps track of the server threads that are ready to process invocations and the client threads that are waiting to process replies.

  When you register your own event handlers with the reactor, the reactor makes an upcall directly into your application code. If your event handler code then makes a remote call and waits for a reply, the LF protocol breaks down since a thread marked as a server thread becomes a client thread without the LF's knowledge. The signature of the problem is a blocked server with stack traces showing none of the threads in the select() system call.

  To fix this problem, you have to abide by the LF protocol. Do the following within your event handler code (e.g., in handle_timeout() or the other handle_* methods):

     TAO_ORB_Core *oc = my_orb->orb_core ();
     oc->lf_strategy ().set_upcall_thread (this->orb_core_->leader_follower ());
  

  You may have to include the header files "tao/ORB_Core.h" and "tao/LF_Strategy.h" in your code to get the above code to compile cleanly. Also, when you make the above calls, remember to use the ORB within whose reactor you registered your event handler.

  Thanks to Milan Cvetkovic <mcvetkovic@mpathix.com> for reporting the problem and to Balachandran Natarajan <bala@dre.vanderbilt.edu> for providing the answer.

  Note: You could also solve the problem by configuring the ORB to use a different wait strategy other than the default Leader Follower.
  See LINK:152: for more information.

  Or, you could use a different ORB (other than the server ORB) in your event handler for making the outbound invocation.

• How can I fix the follwing linker errors from VC71 or VC8 when using IDL sequences of basic types? ⊲

  If you see the following (or similar) linker errors...

   TAO.lib(TAO.dll) : error LNK2005: "public: void __thiscall
          TAO::unbounded_value_sequence<int>::length(unsigned int)"
          ([mangled name removed]) already defined in fooC.obj
  

  ...and the IDL file foo.idl contains a typedef of a sequence of basic types like so... (basic types are types defined by the OMG IDL spec like string, long, etc.)

   typedef sequence<unsigned long> MyULongList; 

  ...the problem is that both your library or exe (from fooC.obj) and TAO.dll are exporting the same class (instantated from the sequence template). Until and unless this issue is fixed for good in the IDL compiler (see DOC group bugzilla entry 2703), use one of the following work-arounds:

  • Instead of typedef'ing your own MyULongList, use CORBA::ULongSeq or similar.
  • Add #include <tao/orb.idl> (which includes tao/ULongSeq.pidl) to the top of your IDL file, or just the include statement for the sequence type(s) that you are using (such as tao/ULongSeq.pidl).

  Either of these work-arounds will force the compiler, when building fooC.obj from fooC.cpp, to see the exported class in the TAO library's headers and avoid re-exporting it.

• Why does one misbehaving Notification service consumer stop events to other consumers of the same channel? ⊲

  The channel's global queue was filled by the bad consumer.

  When the MaxQueueLength admin property is set on a channel without setting MaxEventsPerConsumer QoS property or setting MaxEventsPerConsumer >= MaxQueueLength then a single slow/misbehaving consumer's queue can fill up the entire channel's queue. The full channel queue results in no events getting queued for some or all of the remaining consumers. The events that are not enqueued can result in a memory leak.

  When setting the MaxQueueLength admin property, set the MaxEventsPerConsumer QoS property to a value less than the MaxQueueLength.

Interoperability Issues ⊲

• Why does Orbix 2000 reject large messages from TAO? ⊲

  (as related by Balachandran Natarajan bala@cs.wustl.edu)

  By default, Orbix 2000 will reject any message larger than 512 KB.

  Orbix 2000 users can get around this by setting a run time policy in their configuration file. The policy is
  

    policies:iiop:buffer_sizes_policy:max_buffer_size = "-1";
  

  
  

• What ORBs does TAO interoperate with? ⊲

  There are many different interpretations of the word "interoperate". In general, TAO works with any ORB that adheres to the relevant OMG CORBA standards. If it doesn't work, then there is a bug in one of the ORB implementations. If it is with TAO it is usually corrected quickly (even quicker if you help document and debug the problem). Other ORB implementors also fix these problems quite quickly when they are brought to their attention.

  There is no definitive list of ORBs that a particular version of TAO works with. Here are some ORBs that users have reported successfully using with TAO in the past:
  

  • Orbix (3.x, 2000)
  • Visibroker
  • JacORB
  • OpenORB
  • Sun JDK ORB
  • ORBExpress
  • INTERSTAGE
  • CorbaScript
  • Orbacus
  • ZEN
  • MICO
  • OmniORB
    

  There are probably others.
  
  

• Is the TAO Naming Service interoperable with the JDK 1.4 beta 3 ORB? ⊲

  JDK 1.4 supports Interoperable Object References (IORs). To use the JDK 1.4 ORB with the TAO Naming Service server:

  Start TAO Naming Service server:

    $ $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service -ORBListenEndpoints iiop://host:port
  

  Then, run the JDK 1.4 client as follows to use the TAO Naming Service:

    $ java MessengerClient \
        -ORBInitRef NameService=corbaloc:iiop:host:port/NameService
  

  Here is a sample Java client:

   public class MessengerClient {
    public static void main( String[] args )
    {
      try {
          
        org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args, null);
        // resolve the naming service 
        org.omg.CORBA.Object obj =
          orb.resolve_initial_references("NameService");
        NamingContext rootContext = NamingContextHelper.narrow( obj );
        // create sample  name(sever binding)
        NameComponent[] name = { new NameComponent( "example", "" ),
                                 new NameComponent( "Messenger", "" ) };
        // resolve the server reference
        obj = rootContext.resolve(name);
        Messenger msgr = MessengerHelper.narrow(obj);
        ..............
        ...........
      } catch ( Exception e ) {
         System.err.println( "ERROR: " + e );
          e.printStackTrace( System.err );
      }
    }
  } 

Realtime/Performance/Embedded Systems Issues ⊲

• Where can I see performance comparisons between TAO and <some other ORB>? ⊲

  It's not as easy to compare the performance of ORBs as generically as one might compare, e.g., the performance of microprocessors. There are no standard benchmarks available at the present. Thus, any evaluation of performance of an ORB is largely dependent on the application and its characteristics as well as the environment in which it's running (such as over an ATM network vs. ethernet vs. wireless, etc.).

  That said, you might be able to get a better feeling of the situations in which various ORBs "shine" (performance-wise) by looking at some of the benchmarks available through the following links:

  • Distributed Systems Research Group, Charles University, Prague
  • Dan Kegel's CORBA Page
  • LMCO Advanced Technology Labs' Middleware Comparator

  Finally, don't forget that nothing comes without a cost, so carefully evaluate the entire ORB package, not just the performance.
  

• How can I minimize the sizes of the ACE and TAO libraries? ⊲

  There are several ways to minimize the sizes of the ACE and TAO libraries, at least in UNIX. They are described briefly here. More details can be found in the TAO Developer's Guide.

  Note that all of these solutions are applied at compile time, so if you obtained OCI's Distribution of TAO as pre-built binaries on CD, you will need to re-compile.

  1. Turn off debugging.

     To turn off the generation of extra debugging information in the libraries, use the debug=0 make flag when building the ACE, TAO, and orbsvcs libraries. You can do this in your $ACE_ROOT/include/makeinclude/platform_macros.GNU file by putting debug=0 in the file or when you invoke the make command (e.g., make debug=0).

  2. Build only the ACE components needed for TAO.

     By default, all the ACE components are compiled and included in the ACE library. But, TAO depends upon only a subset of ACE. To build only those components needed for TAO, set ACE_COMPONENTS=FOR_TAO either as an environment variable or in your platform_macros.GNU file.

  3. Build only the "Minimum CORBA" features.

     The TAO library can be built according to the "Minimum CORBA" specification by excluding support for certain features such as DII, DSI, DynAny, and Servant Managers. To select the Minimum CORBA subset of TAO, define the TAO_HAS_MINIMUM_CORBA preprocessor macro in $ACE_ROOT/ace/config.h, or set minimum_corba=1 in your platform_macros.GNU file, or pass minimum_corba=1 on the GNU make command line.

  4. Use the "soreduce" tool to build a minimal set of shared libraries for your application.

     "soreduce" allows you to reduce the sizes of the ACE and TAO libraries by including only the object files that contain symbols used by the relevant executables. "soreduce" generates MPC files that can be used to build subsetted versions of the ACE/TAO libraries.

     For more information on soreduce, see $ACE_ROOT/apps/soreduce/README.

  IMPORTANT

  You should use the size command instead of measuring the size of each library file on disk (e.g., with ls -l) to get a more accurate measure of the true size of the code in the library. The ls -l command reports the size of the library file on disk (which can be very large) while the size command ("dec" column, which is the total of the "text", "data", and "bss" columns, in decimal) reports the run-time size, which will be much smaller. (The "bss" section is unitialized data, according to the Solaris size(1) man page.)

  You can also use the size command to measure the size of an executable.

  The size of each library's file on disk, as reported by ls -l, is actually somewhat irrelevant to the run-time size of your executable, for the following reasons:

  • If you are linking statically, most linkers will link into the executable only those parts of the library (the .o's) that you are actually using in your application.
    
  • If you are linking dynamically, the entire shared library will be loaded into memory, but it will be shared across all processes running on that host that are using the library. So, you only take the memory hit for the library once.
    
  • Also, even in a shared library situation, you are not likely to have the entire library resident at once. Most modern operating systems will page portions of the library file in and out of memory as needed by processes.

  Depending upon your linker and operating system, your mileage may vary.
  
  

• My platform doesn't have a filesystem; how can I use service configurator directives? ⊲

  Many embedded systems don't have filesystems, which really puts a cramp in using the svc.conf file and its directives (e.g., for the Resource_Factory).

  However, you can pass Service Configurator directives on the "command line" using the -ORBSvcConfDirective (Section 7.4 in the TAO Developer's Guide).

  For example, you might put code like the following in your main():
  

    ACE_ARGV orb_args(
      "-ORBSvcConfDirective "
      "\"static Resource_Factory '-ORBResources tss'\"");
    CORBA::ORB_var orb = CORBA::ORB_init(orb_args->argc(),
                                         orb_args->argv());
  

  
  

• Running a thread pool ORB ⊲

  The trick is to configure TAO to use the thread pool reactor and then to call orb->run() from a number of threads, thereby enabling each thread to service incoming requests.

  Selection of the reactor is done through the use of the resource factory, a service config object. If you are using a service configuration file, such as svc.conf, add a line:

    static Resource_Factory '-ORBReactorType tp'
  

  If you cannot use a configuration file, add the following to your command line:

    -ORBServiceDirective "static Resource_Factory '-ORBReactor TP'"
  

  Note that if you are already configuring the resource factory for any other behavior, do not add a new directive line, just add "-ORBReactor TP" to the arguments already passed to the resource factory.

  Now that you have the correct reactor selected, you must invoke ORB::run() from within the threads that are members of the thread pool. The easiest way to achieve this is to derive from ACE_Task, override the svc() method to run the orb, and then use the activate method to start the desired number of threads.
  For example:

    class my_ORB_Pool : public ACE_Task <ACE_MT_SYNCH>
    {
    public:
      virtual int open (void *arg);
      virtual int svc (void);
    private:
      CORBA::ORB_ptr orb_;
    };
  
    // A reference to the ORB must be supplied to the object, via open
    int
    my_ORB_Pool:: open (void *arg)
    {
      orb_ = ACE_static_cast (CORBA::ORB_ptr,arg); 
      return 0;
    }
  
    // ACE_Task::activate calls svc() in as many threads as we specify
    int
    my_ORB_Pool::svc (void)
    {
      orb_->run();
      return 0;
    }
  
    //Now, start it going
  
    int
    main (int argc, char ** argv)
    {
      // normal program initialization business
      my_ORB_Pool orb_pool;
  
      // initialize the orb, which also loads the correct reactor
      CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    
      int nthreads = 42; // the number of threads in the pool
  
      orb_pool.open(orb);
      orb_pool.activate (ACE_NEW_LWP,nthreads); // nthreads = 1 is normal 
                                            // reactive behavior
  
      ACE_Thread_Manager::instance->wait(); // wait for all threads
      return 0;
    }
  
  

  
  

• Does TAO support request/reply timeouts? ⊲

  TAO supports the Relative Roundtrip Timeout policy as defined in the CORBA Messaging specification (OMG Document formal/04-03-12, Chapter 22). This policy allows you to specify the maximum time allowed (in 100 nanosecond units) for a request to be sent to and processed by a server and the reply received by the client. The policy can be applied at one of three levels: the client ORB, the requesting thread, or the object reference on which the request is invoked.

  Relative roundtrip timeouts can be applied when the client requires low request/reply latencies.

  The following example shows how to set the Relative Roundtrip Timeout policy to a value of 1 millisecond (that is 1.0e-3 * 1.0e7 in 100 nanosecond units) and apply it at the ORB level:

    // Initialize the ORB.  It serves as a factory for policies.
    CORBA::ORB_var orb = CORBA::ORB_init (argc, argv);
  
    // Set the timeout value as a TimeBase::TimeT (100 nanosecond units)
    // and insert it into a CORBA::Any.
    TimeBase::TimeT relative_rt_timeout = 1.0e-3 * 1.0e7;
    CORBA::Any relative_rt_timeout_as_any;
    relative_rt_timeout_as_any <<= relative_rt_timeout;
  
    // Create the policy and put it in a policy list.
    CORBA::PolicyList policies;
    pols.length(1);
    policies[0] = 
      orb->create_policy (Messaging::RELATIVE_RT_TIMEOUT_POLICY_TYPE,
                          relative_rt_timeout_as_any);
  
    // Apply the policy at the ORB level using the ORBPolicyManager.
    CORBA::Object_var obj =
      orb->resolve_initial_references ("ORBPolicyManager");
    CORBA::PolicyManager_var policy_manager = 
      CORBA::PolicyManager::_narrow (obj.in());
    policy_manager->set_policy_overrides (policies, CORBA::SET_OVERRIDE);
  

  All requests made via this ORB will now timeout if a reply is not received within 1 millisecond. When a timeout occurs, the ORB will raise a CORBA::TIMEOUT system exception. The client can then take whatever action is necessary to handle the failure. If a reply eventually arrives after the timeout period has expired, it will be discarded by the client ORB.

  The Relative Roundtrip Timeout policy, and other Quality of Service policies defined as part of the CORBA Messaging specification, are described in more detail in the OCI TAO Developer's Guide, CORBA Messaging chapter, available from {{site.baseurl}}/. See also http://www.cs.wustl.edu/~schmidt/PDF/C++-report-col19.pdf.
  
  

• What IDL compiler options help reduce the footprint? ⊲

  Footprint Reduction in Generated Code

  IDL Compiler Command Line Options

  -Sa	Suppresses generation of Any insertion/extraction operators, and generates certain portable interceptor operations that use Anys as dummies
  -St	Suppresses type code generation. Since Anys depend on type codes, this options also does what -Sa does.
  -Gt	Generate optimized typecodes. All the string names in a type code except the repository id will be null with this option. This optimization is allowed by the, CORBA spec, but it may cause problems when trying to determine type code equivalence.
  -Sc	Suppresses tie class generation.
  -Sp	Suppresses the generation of thru-POA collocated stub code.
  -Sd	Suppresses the generation of direct collocated stub code. Direct collocation stub code generation is disabled by default, but the option is included for completeness.
  -Sv	Suppresses code generation for valuetypes. Code generation for valuetypes is disabled by default, but the option is included for completeness.

  C++ Compiler Options

  If both TAO and the application are compiled with TAO_HAS_INTERCEPTORS defined to be 0 (either by passing to the C++ compiler or by redefining the macro in ACE_ROOT/TAO/tao/orbconf.h) not only will the TAO library be smaller, but also the application object code, since the C++ preprocessor will skip the generated interceptor classes and parts of the code generated for each IDL operation.

• How can I reduce my compile time during development? ⊲

  Reducing compile time during development:
  
  Disable Optimization:

  When developing software that uses ACE+TAO you can reduce the time it takes to compile your software by not enabling you compiler's optimizer flags. These often take the form -O.

  Disabling optimization for your application will come at the cost of run time performance, so you should normally only do this during development, keeping your test and release build optimized.

  
  Disable Inlining:

  When compiler optimization is disabled, it is frequently the case that no inlining will be performed. In this case the ACE inlining will be adding to your compile time without any appreciable benefit. You can therefore decrease compile times further by build building your application with the -DACE_NO_INLINE C++ flag.

  In order for code built with -DACE_NO_INLINE to link, you will need to be using a version of ACE+TAO built with the "inline=0" make flag.

  In order to accommodate both inline and non-inline builds of your application it will be necessary to build two copies of your ACE+TAO libraries, one with inlining and one without. You can then use your ACE_ROOT and TAO_ROOT variables to point at the appropriate installation.

Miscellaneous platform-specific Issues ⊲

• What's the minimum set of directories I need to build to be able to develop applications with ACE and TAO? ⊲

  One common way to build ACE and TAO (once you have your configuration set up) is to simply run "make" in the $ACE_ROOT directory, then run "make" again in the $TAO_ROOT directory. However, running "make" from $ACE_ROOT not only builds the ACE library, it also builds all of the examples, tests, and other things you may not need. Likewise, running "make" from $TAO_ROOT builds not only the TAO and orbsvcs libraries, it also builds all the TAO and orbsvcs tests and examples.

  To build only what you need to develop applications with ACE and TAO (and to save LOTS of disk space while building) you can run make in only the following directories:
  

    $ACE_ROOT/ace
    $ACE_ROOT/apps/gperf/src
    $TAO_ROOT/TAO_IDL
    $ACE_ROOT/ACEXML
    $TAO_ROOT/tao
    $ACE_ROOT/protocols
    $TAO_ROOT/orbsvcs/orbsvcs

  This will build only the ACE library, gperf executable (needed by the IDL compiler), tao_idl executable, ACEXML library, protocol libraries (extensions of the ACE framework), TAO libraries, and orbsvcs libraries.

  If you want to also build any of the orbsvcs executables (e.g., $TAO_ROOT/orbsvcs/Naming_Service), add their directories to the set of directories that you build. For example:

    cd $TAO_ROOT/orbsvcs/Naming_Service
    make
  

  You may also find the "nslist" and "catior" utilities very useful, so you probably should also add these directories to the list of directories in which to build:
  

    $TAO_ROOT/utils/nslist
    $TAO_ROOT/utils/catior
  

  Of course, you can always go back and build individual tests and examples if you want to.
  

• Why can't my client connect to a server running on a wintel host with dialup networking? ⊲

  See LINK:130: for a possible solution.

  
  

• What issues are involved when using MFC with ACE/TAO? ⊲

  You can add an ACE_HAS_MFC conditional #define to your ace/config.h file.
  It is only necessary to use ACE_HAS_MFC if you wish threads created and managed by ACE to be able to make MFC calls. The ACE_HAS_MFC setting causes ACE to use CWinThread worker thread objects for all threads. ACE will still manage these threads just the same as threads created by _beginthreadex(). The only difference is the extra thread-local data stored in the threads. Refer to the many articles on MSDN for when to use AfxBeginThread vs _beginthread, and which MFC functions require CWinThreads. There are quite a few subtle problems. For instance, you typically can't use an MFC wrapper object created in one thread in another. (By wrapper object, I mean those that wrap windows handles. CDC, CWnd, ...) (The typical solution is to pass the handles betweeen threads.) --- In summary, if you find that you really do need to make MFC calls from ACE threads then use the MFC build of the ACE library, however it is typically not necessary because the layer of software using ACE/TAO is often separated from the layer using MFC.
  

• Are there any project wizards for Borland C++ Builder? ⊲

  Yes, Christopher Kohlhoff (chris@kohlhoff.com) has developed these and made them available at http://www.tenermerx.com/programming/corba/tao_bcb/using/index.html .
  

Windows-based platforms ⊲

• Does OCI's version of TAO contain MFC libraries? ⊲

  MFC Libraries are libraries built with the ACE_HAS_MFC variable defined. See LINK:137: for more details of what this means.

  The OCI-produced binary installation kits do not contain MFC libraries for Windows platforms. You will need to recompile ACE and TAO in order to build them with MFC libraries.

  
  

• Why do I encounter linking errors when building Debug applications in Windows with Visual C++? ⊲

  If you're linking debug versions of an executable or DLL and have unresolved symbols, there are several possible reasons:
  

  1. Is your library path correct?
     (Check Tools|Options|Directories|Libraries or your project settings.)
     
  2. Are you linking in the ACE, TAO, and possibly orbsvcs libraries?
     (Check Build|Settings|Link)
     
  3. Are you linking with the right library names?
     If you are building your application against a Debug configuration of ACE+TAO, the names of the libraries will have the letter "d" in them (e.g., aced.lib, TAOd.lib, CosNamingd.lib). If you are using a Release configuration of ACE+TAO, the "d" will not be present in the library names.
     
  4. Have you installed or built the Debug configuration of ACE+TAO?
     If you have only installed the non-Debug version of TAO, you will not be able to build Debug executables. To check this, do one of the following:
     1. Build the Release configuration of the executable; or
     2. Remove _DEBUG from the list of preprocessor definitions.
     If the build succeeds, then you probably have a non-Debug version of TAO.
     

  
  

• How do I export generated classes from DLLs? ⊲

  According to the TAO Developer's Guide, TAO IDL Compiler chapter, section on "Back End Options", the way to export generated classes is as follows:
  

  1. Create an export header file using the perl script %ACE_ROOT%\bin\generate_export_file.pl:

       generate_export_file.pl Foo > FooExport.h
     

  2. Use the -Wb,export_macro and -Wb,export_include options to the TAO IDL compiler to include the macros in the generated class declarations:

       tao_idl -Wb,export_macro=Foo_Export -Wb,export_include=FooExport.h Foo.idl
     

  3. In the project settings, C/C++ tab, preprocessor options, include FOO_BUILD_DLL in the list of definitions.
     (If you use MPC to generate your project settings, the last step is done for you automatically.)

  See the TAO Developer's Guide for more information and examples.

• Why doesn't using the Naming Service with Multicast work? ⊲

  At least on some versions of Windows, there's a bug in which the TTL (Time-to-Live) field in multicast IP packets is set to zero. Thus, nobody pays attention to those packets. This particular problem bit OCI in their training lab environment, and for this reason we now use the Naming Service without multicasting as documented in the TAO Developer's Guide (see LINK:004:).

  The problem is documented in http://support.microsoft.com/support/kb/articles/Q234/9/80.ASP. Although the notes say to get the latest Service Pack, our experience shows that this doesn't help as of Service Pack 6.
  

• How do I link against multithreaded libraries in Visual C++? ⊲

  Select the Project -> Settings menu item
  Select the C/C++ tab.
  Set the Category to Code Generation
  Under Run-time library select one of the multithreaded libraries

  
  

• When I use the ACE_Process_Manager to launch my process, why does the reactor fail to initialize? ⊲

  Either inherit the environment (via ProcessInfo) or set the SystemRoot environment variable to C:\WINDOWS or the appropriate place for windows install.

• Which project settings should I change to ensure acemfc.lib is built? ⊲

  Change the active configuration:
  From the "Build" pull down menu choose "Set Active Configuration...". In the Configuration popup choose the appropriate (Debug or Release) MFC configuration.

  Batch build:
  Go to the Build pull-down in MSC++ and select the Batch Build option. When the batch build window pops up select the ACE MFC build option and deselect all the other options. This will build the acemfc.lib for you. Using batch build option you can build all the flavors of the various ACE and TAO libraries you need.

• How do I instantiate a singleton from a DLL? ⊲

  Singletons in DLLs on Windows
  If you want to instantiate a singleton in a DLL on Windows, follow these steps:

  1. Use generate_export_file.pl (found in ACE_wrappers/bin) to generate the proper Win32 export directives for your dll. For example, "perl generate_export_file.pl MyLib >MyLib_Export.h" generates the following output in the file "MyLib_Export.h":

     
       // -*- C++ -*-
       // generate_export_file.pl,v 1.8 2001/03/04 09:16:29 nanbor Exp
       // Definition for Win32 Export directives.
       // This file is generated automatically by generate_export_file.pl
       // ------------------------------
       #ifndef MYLIB_EXPORT_H
       #define MYLIB_EXPORT_H
     
       #include "ace/config-all.h"
     
       #if !defined (MYLIB_HAS_DLL)
       #  define MYLIB_HAS_DLL 1
       #endif /* ! MYLIB_HAS_DLL */
     
       #if defined (MYLIB_HAS_DLL) && (MYLIB_HAS_DLL == 1)
       #  if defined (MYLIB_BUILD_DLL)
       #    define MyLib_Export ACE_Proper_Export_Flag
       #    define MYLIB_SINGLETON_DECLARATION(T) \
                     ACE_EXPORT_SINGLETON_DECLARATION (T)
       #    define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) \
                     ACE_EXPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK)
       #  else /* MYLIB_BUILD_DLL */
       #    define MyLib_Export ACE_Proper_Import_Flag
       #    define MYLIB_SINGLETON_DECLARATION(T) \
                     ACE_IMPORT_SINGLETON_DECLARATION (T)
       #    define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK) \
                     ACE_IMPORT_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK)
       #  endif /* MYLIB_BUILD_DLL */
       #else /* MYLIB_HAS_DLL == 1 */
       #  define MyLib_Export
       #  define MYLIB_SINGLETON_DECLARATION(T)
       #  define MYLIB_SINGLETON_DECLARE(SINGLETON_TYPE, CLASS, LOCK)
       #endif /* MYLIB_HAS_DLL == 1 */
     
       #endif /* MYLIB_EXPORT_H */
     
       // End of auto generated file.
     

  2. When declaring your singleton, make sure and use the right export directive that you generated for your dll. For instance, if you create a class that is meant to be a singleton in MyLib.dll, you'd typically do this:

     
       class MyLib_Export MyClass
       {
       };
     
       typedef ACE_Singleton<MyClass, ACE_Null_Mutex> MY_CLASS_SINGLETON;
       MYLIB_SINGLETON_DECLARE(ACE_Singleton, MyClass, ACE_Null_Mutex);
     

• Why does my TAO application leak memory when using Windows threads? ⊲

  On Windows, if one spawns a thread with, for example _beginthreadex, and makes CORBA calls from that thread, TAO will leak memory. TAO uses TSS (thread specific storage) for handling requests along the output data paths. With Win32 threads, the underlying type system does not invoke destructors on TSS and the application will leak memory. To get around this problem, please use ACE threads wherever possible. Thanks to <alexander.jasper@gmx.net> for supplying this FAQ!

VxWorks ⊲

• I've just built the libraries and they're HUGE...how can I make them smaller? ⊲

  See LINK:019: for a more general discussion of TAO program/library sizes.

  This all depends upon your definition of "huge" and how you built the libraries. If you consider a few megabytes to be huge and you've built optimized, nodebug, and minimum CORBA, then that's the way life is currently.

  If, on the other hand, you're looking at the size of the files and you built the defaults, then the first thing you need to do is understand that the size of the file is NOT the same as the size of the code. When compiling with debug information, the compiler adds symbol information to the libraries, and that symbol information is massive. What you need to do is look at the code size. Using the WindRiver GNU toolchain, you can use sizeppc to do this, e.g.,
  

    $ sizeppc libACE.so
    text    data    bss     dec     hex     filename
    626392  65036   1316    692744  a9208   libACE.so
  
    $ ls -l libACE.so
    -rwxrwxr-x   1 cleeland distcomp 31181587 Mar 16 10:10 libACE.so*
  

  So, you can see that the file size is 30Mb, but the code size is 692k. Quite a different number. The "size" results can be compared to the available memory on the target system. Use both the "memShow" and "adrSpaceShow" commands from the target-resident VxWorks shell to see how much memory is available.

  There are various strategies for making the libraries smaller, and all involve rebuilding. Specifically, you can build:

  • nodebug (debug=0) which will eliminate symbols and debugging messages
    
  • minimumCORBA, which will only compile functionality specified by the Minimum CORBA specification
    
  • ACE only for TAO, which will only compile the portions of ACE required by TAO

  
  An often-used technique for keeping library sizes small and still debuggable is to build the entire library nondebug, then only build the pieces you need to debug with debug on. This allows you to debug those pieces, but not suffer through the problems that large file sizes in libraries cause (e.g., longer download/boot times).
  Here is a shortcut to rebuilding a lib with debug=0. But:

  1. It doesn't remove debugging statements.
  2. You have to be careful to not remove relocation symbols on VxWorks, so that you can load the lib. For example, use something like stripppc --strip-unneeded, or strip386 --strip-debug
  3. stripppc is broken on Tornado 2, Windows host. It won't let you create the output file, so it's not of any use.

• How do I create shared libraries? ⊲

  Shared libraries on VxWorks aren't really shared libraries. If you ever worked on Unix in the days before shared libraries, you might remember "relocatable object files", i.e., object files created by the linker with many of their symbols resolved, but also permitted to have unresolved symbols.

  When you see libACE.so on VxWorks, they're simply relocatable object files. Once you realize that, and all it entails, your life will get easier :-)

  Some implications of this are:

  • You should not use "-lACE" when linking libTAO.so, then try to load both libACE.so and libTAO.so. This will lead to duplicate symbols because the creation of libTAO.so will resolve all the ACE symbols. Thus, when you load libTAO.so after having loaded libACE.so, you will, effectively, load all the symbols in libACE.so again (they're in libTAO.so, too).
  • Similar to the previous point, you should not link libACE.so or libTAO.so into your application.

  A command line to create a shared library on VxWorks might look like:

    $ make shared_libs_only=1 ACE_SHLIBS= 

  The ACE_SHLIBS make macro usually contains the names of shared libraries to link in, such as "-lTAO -lACE", etc. By making it empty, these do not get linked.
  

• On VxWorks 6.2 upon execution I see the following error message "ERROR: input in scanner failed "? ⊲

  This message indicates that the service configurator failed to read the configuration file for some reason. On VxWorks 6.2 we have seen this message because of a bug in the NFS V2 driver wherein the driver returns a corrupt file handle when opening a non-existent file. If a config file hasn't been specified, the service configurator tries to open the default config file 'svc.conf'. Trying then to read in from the returned corrupt file handle results in the above message.

  This issue is documented in defect #55808. A fix for this is documented this whcih requires a kernel rebuild. A quick work around is to create a dummy svc.conf file. Another workaround is LINK:disregard_default_svc_conf:.

• How can I configure TAO to disregard the default configuration file 'svc.conf'? ⊲

  In the past this was done by setting 'fakesvcconf =1' in the platform_macros.GNU. However this has been deprecated in 1.5a. The current recommendation is to define TAO_PLATFORM_SVC_CONF_FILE_NOTSUP in $ACE_ROOT/ace/config.h. This is also backwards compatible with 1.4a and 1.3a.

TAO and Java ⊲

• Is there a Java version of TAO? ⊲

  Yes, and no. It's called Zen.

  Check out LINK:075:.

  Note that you can use any CORBA compliant ORB with TAO. The most popular Java-based ORB used with TAO is JacORB. See LINK:JacORB: for more details.
  
  

• Does TAO support a Java binding? ⊲

  TAO is a C++ ORB. Any other CORBA compliant ORB can interoperate with TAO (as well as other CORBA compliant ORBs). There are several free Java ORBs available, such as JacORB. For more information on TAO and JacORB, see LINK:JacORB:.

  Work on a real-time Java ORB, ZEN, is currently in progress. For more information, see LINK:075: or http://www.zen.uci.edu/.

  
  

• Is TAO interoperable with Sun's Java JDK 1.3 ORB? ⊲

  Yes, but there is an issue with Codesets supported by Sun's Java 1.3 ORB.

  Sun's Java 1.3 ORB does not support character sets UTF-8 and UTF-16. To use Sun's Java 1.3 ORB with TAO, you must disable the generation of optional standard profile components in IORs generated by TAO. To do so, use the following ORB initialization option with TAO servers that generate IORs that will be used by Java 1.3 ORB clients:

      -ORBStdProfileComponents 0

  Thanks to Gordana and Kate Matic gordanam@ot.co.nz for posing the original question and Carlos O'Ryan coryan@uci.edu for providing the answer.
  

• Is TAO interoperable with JacORB? ⊲

  Yes, TAO is interoperable with JacORB. In fact, several versions of both TAO and JacORB have been tested together over the last several years.

• How can I use TAO with Java's tnameserv? ⊲

  Using tnameserv as the naming service implementation.

  [From material originally posted to tao-users by Carlos O'Ryan.]
  Suppose that you have a CORBA application written with TAO, and you want to use the Java naming service implementation (tnameserv):

    $ tnameserv -ORBInitialPort 1050 &;
  

  In order for your CORBA application to use this naming service instance, you need to somehow get the IOR for the instance (exercise left to the reader). Once you get it, you can provide it to your TAO-based CORBA application using the -ORBInitRef NameService=... command line option. For example, if you have the IOR as a string, you can use:

    $ app -ORBInitRef NameService=IOR:....
  

  Similarly, if the IOR is in a text file, you can use:

    $ app -ORBInitRef NameService=file://path/to/file.txt
  

  Finally, if you were so lucky for your version of tnameserv to implement the Interoperable Naming Service specification (doubtful at the moment), you could use:

    $ app -ORBInitRef NameService=corbaloc:iiop:host:port/NameService
  

  In older versions of TAO (before 1.1.10) this option takes the following form:

    $ app -ORBInitRef NameService=iioploc://host:port/NameService
  

  
  

• How can I use TAO's Naming Service with my Java ORB? ⊲

  When I use the TAO name service, JavaORB returns an org.omg.CORBA.INV_OBJREF in resolve_initial_references("NameService").

  There's a file called NS_Resolve.java in
  

      $TAO_ROOT/examples/Simulator/DOVEBrowser
  

  that contains code which discovers TAO's Naming Service via the multicast discovery mechanism. Hooking that into the initial references table is ORB-specific, however.

  Alternately, you can bypass the TAO Naming Service's multicast mechanism and connect your Java application to it directly. For an example which uses TAO and JacORB, see LINK:074:

  
  

• What is ZEN? ⊲

  ZEN is a real-time Java ORB being developed by the Distributed Object Computing groups at the University of California, Irvine and Washington University in St. Louis.

  ZEN is currently under development. For more information, see http://www.zen.uci.edu/.

  A ZEN mailing list is available. To subscribe, see http://doc.ece.uci.edu/cgi-bin/mailman/listinfo/zen-users.

  
  

TAO and JacORB ⊲

• What is JacORB? ⊲

  JacORB is an open source Java ORB that is most often used with TAO. To learn more visit the home page or OCI's JacORB Support Page.

• How can I ensure that the Java JDK is using JacORB rather than its own ORB? ⊲

  Java uses a properties file called "orb.properties" to determine which ORB to use. If the Java runtime doesn't find an orb.properties file, it uses the JDK's ORB.

  JacORB's orb.properties file is located in the top-level JacORB directory. Copy JacORB's orb.properties file into the Java JDK's ${java.home}/lib directory to enable JacORB. If you're not sure which directory this is, compile and run the following Java program:

    public class InstallHelper
      {           
         public static void main( String[] args )
         {
             System.out.print("orb.properties should be copied to ");
             System.out.print( System.getProperty("java.home") );
             System.out.print( System.getProperty("file.separator")
                               + "lib" );
         }
      }
  

  A sure sign that the Java runtime is not using JacORB is that an exception is thrown, and the stack trace contains methods with the prefix "com.sun.corba".

  
  An alternative way to specify which ORB to use is to specify it directly to the Java runtime.

  Instead of the orb.properties file in the lib directory you can just pass the following to the virtual machine:

  JacORB 1.3.11 or earlier:

    -Dorg.omg.CORBA.ORBClass=jacorb.orb.ORB
    -Dorg.omg.CORBA.ORBSingletonClass=jacorb.orb.ORBSingleton
  

  JacORB 1.3.21 or later:

    -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB
    -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton
  

  For example:

    java -classpath %CLASSPATH%;C:\Java\JacORB1_3_21\lib\jacorb.jar
       -Dorg.omg.CORBA.ORBClass=org.jacorb.orb.ORB 
       -Dorg.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton 
       com.ociweb.appname.Main
  

  
  A second alternative way to specify which ORB to use is to specify it directly in your code when you initialize the ORB.

  Instead of copying the orb.properties file in the ${java.home}/lib directory, put the following in your main program:

  JacORB 1.3.11 or earlier:

    java.util.Properties props = new java.util.Properties();
    props.put( "org.omg.CORBA.ORBClass", 
               "jacorb.orb.ORB" );
    props.put( "org.omg.CORBA.ORBSingletonClass", 
               "jacorb.orb.ORBSingleton" );
    org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, props );
  

  JacORB 1.3.21 or later:

    java.util.Properties props = new java.util.Properties();
    props.put( "org.omg.CORBA.ORBClass", 
               "org.jacorb.orb.ORB" );
    props.put( "org.omg.CORBA.ORBSingletonClass",
               "org.jacorb.orb.ORBSingleton" );
    org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, props );
  

  
  

• My TAO server publishes an object reference to my JacORB client, but the "narrow" call is failing on the client. What should I do? ⊲

  Check to see that Interface Repository Ids generated by TAO and JacORB for each interface are the same.
  For example, suppose you have an IDL file called "Bank.idl", with an IDL interface called "Bank".
  TAO generates a file called BankC.cpp; in that file, in the Bank class, there is an "_interface_repository_id" function. That function should return a string that looks something like this:
  

      "IDL:Bank:1.0"
  

  JacORB generates a Java file called BankHelper.java. In that file, in the BankHelper class is an "id" function. It also returns a string, and that string must match TAO's _interface_repository_id string exactly:
  

      "IDL:Bank:1.0"
  

  Incidentally, both TAO and JacORB's IDL compiler support the #pragma prefix directive in IDL files.
  
  

• Does JacORB support the "iioploc" object reference format? ⊲

  No, JacORB (as well as versions of TAO 1.1.10 and later) uses the "corbaloc" object reference format. See LINK:073: for more information about using "corbaloc" object references between JacORB (or any client) and TAO servers.

  
  

• How do I use JacORB with TAO's Naming Service? ⊲

  JacORB applications can use TAO's Naming Service. Applications implemented with Java JDK 1.2 or later require a workaround to avoid using Sun's org.omg.CosNaming stubs, which are buggy. We'll use the -Xbootclasspath/p runtime option to eliminate that problem, as described below.

  The steps for using TAO's Naming Service from JacORB clients are as follows:

  1. Start TAO's Naming Service, specifying a well-known listening endpoint
     

      $TAO_ROOT/orbsvcs/Naming_Service/Naming_Service \
       -ORBListenEndpoints iiop://myhost:2809
     

  2. Write your JacORB Naming Service clients as you normally would, using orb.resolve_initial_references("NameService") to find the Naming Service.
     

       import org.omg.CORBA.ORB;
       import org.omg.CosNaming.*;
       import org.omg.CosNaming.NamingContextPackage.*;
     
       public class NSTest {
         public static void main(String args[]) {
           try{
             ORB orb = ORB.init(args, null);
             
             org.omg.CORBA.Object o = 
               orb.resolve_initial_references( "NameService" );
             NamingContext rootNC = NamingContextHelper.narrow( o );
     
             // ...etc...
     
           } catch ( Exception e ) {
             System.err.println("ERROR : " + e) ;
             e.printStackTrace( System.err );
           }
         }
       }
     

  3. Run your Java application using the -ORBInitRef command-line option to tell JacORB where to find the Naming Service. If the Java application is implemented using Java JDK 1.2 or later, then the -Xbootclasspath/p option will be needed to use JacORB's CosNaming stubs instead of the Sun's.

  For the sake of our example, assume JacORB is installed in /usr/don/JacORB-1_2_3.
  

    Java 1.2 or later:
  
      java -Xbootclasspath/p:/usr/don/JacORB-1_2_3/lib/jacorb.jar
           -DORBInitRef.NameService=corbaloc:iiop:myhost:2809/NameService
           NSTest
  
    Java 1.1:
      java -DORBInitRef.NameService=corbaloc:iiop:myhost:2809/NameService
           NSTest
  

  Note that the host and port -- "myhost" and "2809" -- in these object references match the host and port passed into the TAO Naming Service's "-ORBListenEndpoints" argument.

  You can also use JacORB's jacorb.properties file to set the Naming Service IOR:
  

      #
      # jacorb.properties
      #
      ORBInitRef.NameService=corbaloc:iiop:myhost:2809/NameService
  

  And then run the client and server without the -DORBInitRef:
  

    Java 1.2 or later:
  
      java -Xbootclasspath/p:/usr/don/JacORB-1_2_3/lib/jacorb.jar NSTest
  
  
    Java 1.1:
      java NSTest
  

  
  

• I've upgraded to JacORB 1.3.21 (or later), and I'm getting an "org.omg.CORBA.INITIALIZE" exception. What's wrong? ⊲

  In JacORB 1.3.21, the prefix for all JacORB packages has been changed from "jacorb" to "org.jacorb".

  The solution is to edit your orb.properties file to change this:

      org.omg.CORBA.ORBClass=jacorb.orb.ORB
      org.omg.CORBA.ORBSingletonClass=jacorb.orb.ORBSingleton

  to this:

      org.omg.CORBA.ORBClass=org.jacorb.orb.ORB
      org.omg.CORBA.ORBSingletonClass=org.jacorb.orb.ORBSingleton

  Also, you must edit any script or build.xml file that refers to a JacORB class directly.
  
  

• JacORB is using the wrong Ethernet adapter address. What should I do? ⊲

  You can inform JacORB which Ethernet adapter to use by specifing it in the jacorb.properties file (it could also be passed in on the command line). Just set the OAIAddr property to the IP address that you want JacORB to use. For example, on my Windows98 machine which has a DSL modem, JacORB was using the adapter Ethernet address 5.0.0.4 instead of the true public IP address. I modified OAIAddr property and everything worked fine. BTW you can see what address JacORB is attempting to connect to by setting jacorb.verbosity to 2.
  For example:

    java -Djacorb.verbosity=2 -DOAIAddr=12.345.67.89 Client
  

  
  

• JacORB-only Naming Service example ⊲

  A JacORB-only Naming Service example. A JacORB client uses the Naming Service to find its target object. Please see the README and the PDF file in the attached .tgz file (Windows users can use WinZip to open it).
  jacorb-ns-example.tgz (3.8 K)
  ns-example-presentation.pdf (259.6 K)
  

Fault Tolerance ⊲

• How do I enable Fault Tolerance features in the ORB? ⊲

  Make sure the FTORB library is loaded. See $TAO_ROOT/orbsvcs/tests/FaultTolerance/IOGR/svc.conf or svc.conf.xml for an example.
  
  Note: The FT CORBA capabilities of TAO are still under development. The information in this category is subject to change. The status of TAO's Fault Tolerance support is summarized here.

• Why doesn't set_primary() work even though a "primary server" is up-and-running? ⊲

  Make sure Fault Tolerance features have been enabled in the ORB. See LINK:EnableFaultTolerance:

• Why does the client receive a failure (COMM_FAILURE) during failover to a secondary server even though the secondary server received the request from the client correctly? ⊲

  If you use the FTORB library, request/retry should be transparent to the application. If you don't use the FTORB library, you will not get the transparent behavior. See LINK:EnableFaultTolerance:

• Does TAO support the HEARTBEAT_POLICY? ⊲

  No, not yet.

Implementation Repository ⊲

• How can I minimize the overhead of using both the IORTable and ImR? ⊲

  Simply register a direct object reference with the IORTable instead of the indirect one. To obtain the direct object reference you must call a special version of POA::id_to_reference(): TAO_Root_POA* tpoa = dynamic_cast(poa.in()); bool use_indirect = false; Object_var obj = tpoa->id_to_reference_i(oid.in(), use_indirect); String_var direct_ior = orb->object_to_string(obj.in()); ior_table->bind("POAName/ObjectName", direct_ior.in());

• How can I avoid losing my tagged components when I use the ImR and indirect object references? ⊲

  While we don't have an example to showcase this problem, it should be possible to register a direct object reference with the IORTable, as discussed above, to work around this problem.

• Is it possible to register more than one object per POA with the ImR? ⊲

  This is a trick question, because the ImR doesn't know anything about your object references. Any objects activated in a persistent POA will automatically use indirect object references (assuming -orbuseimr 1). However, if you want to support corbaloc URLs such as those generated using "tao_imr ior" then you will need to additionally register your IORs in an IORTable in the server. This is actually completely orthogonal to whether your object references are indirect. However, you *can* avoid unnecessary additional performance overhead by registering *direct* IORs in your IORTable. Here's a short example that registers two objects with one POA. const char* poa_name = "MessengerService"; POA_var poa = createPersistentPOA(root_poa.in(), poa_name); Messenger_i servant1, servant2; ObjectId_var id1 = string_to_ObjectId("Object1"); poa->activate_object_with_id(id1.in(), &servant1); ObjectId_var id2 = string_to_ObjectId("Object2"); poa->activate_object_with_id(id2.in(), &servant2); obj = poa->id_to_reference(id1.in()); String_var ior1 = orb->object_to_string(obj.in()); obj = poa->id_to_reference(id2.in()); String_var ior2 = orb->object_to_string(obj.in()); obj = orb->resolve_initial_references("IORTable"); IORTable::Table_var ior_table = IORTable::Table::_narrow(obj.in()); ior_table->bind("MessengerService/Object1", ior1.in()); ior_table->bind("MessengerService/Object2", ior2.in()); The problem with the above code is that the ImR will redirect clients to the correct server, but then because you are using a corbaloc URL, the server will redirect the clients to the IOR registered in the IORTable. Since these object use inderect references, you'll end up being redirected *back* to the ImR again, which will then finally forward you back to the server where your invocation can continue. The solution is to modify the program to register *direct* object references with the IORTable. TAO_Root_POA* tpoa = dynamic_cast(poa.in()); bool use_indirect = false; obj = tpoa->id_to_reference_i(id1.in(), use_indirect); String_var ior1 = orb->object_to_string(obj.in()); obj = tpoa->id_to_reference_i(id2.in(), use_indirect); String_var ior2 = orb->object_to_string(obj.in()); Now the ImR will redirect clients to the correct server, and then the server will redirect clients back to itself without going back through the ImR.

• How can I avoid the cost of being redirected twice to my server when using the ImR? ⊲

  When using corbaloc URLs, the ImR simply redirects clients to the correct server, however the URL-based object reference doesn't contain enough information to actually do anything. Therefore the server must include an IORTable entry that will be used to redirect the client back to the server itself again with the correct full IOR-based object reference. This extra round-trip can be avoided by simply *not* using URLs to invoke the operations in the first place. This typically means that you'll have to run the server and have it either output the IOR or register it with a NameService. As long as you start the server on a consistent endpoint(s) then the IOR will remain valid.