Contents

General

Building Distributions of ACE and TAO (basic)

OCI-Specific Issues

ORB Services

Security Service & SSLIOP

Boostrapping and Discovery Mechanisms

Runtime Configuration

General/Miscellaneous Questions

Errors, and possible solutions

Interoperability Issues

Realtime/Performance/Embedded Systems Issues

Miscellaneous platform-specific Issues

Windows-based platforms

VxWorks

TAO and Java

TAO and JacORB

Fault Tolerance

Implementation Repository


Answers

General

  • What is this FAQ about?

    This is a FAQ for The ACE ORB (TAO), an open-source CORBA-compliant ORB born of research at Washington University in St. Louis' Center for Distributed Object Computing (http://www.cse.wustl.edu/~doc/). If your question isn't answered here, you might want to check out the following links:

    We at OCI provide commercial-grade support for this ORB, along with documentation and consulting services (see our web page at http://www.objectcomputing.com for more details), and provide the site and content of this FAQ as a free service to the TAO community.

    If you have questions, and especially if you have answers to them, please send them to support@objectcomputing.com for inclusion in this FAQ! Let us know whether you'd like to be credited with the answer and, if so, how.

  • Where can I find the source code for the examples in the TAO Developer's Guide?;

    The source code for all the examples in recent versions of the OCI TAO Developer's Guide is available in the OCI TAO source code distribution, itself. See ACE_wrappers/TAO/DevGuideExamples/. For older versions of TAO and the TAO Developer's Guide, the source code for the examples can be downloaded from our web site. See {{site.baseurl}}/downloads/index.html for more details.
  • What is the best way to start learning CORBA and TAO ?

    Books

    Advanced CORBA Programming with C++ book by Henning and Vinoski. It's the equivalent of the ACE tutorial (except it's much more complete). This is a general C++ CORBA book and covers the standard way of doing things.

    The OCI TAO Developer's Guide, which you can purchase via {{site.baseurl}}/purchase/index.html . This book picks up where the Henning and Vinoski book stops, covering TAO specific topics as well as CORBA standard features omitted from the Henning and Vinoski book.

    Online

    The C++ Report and CUJ columns that Vinoski and Schmidt wrote over the past 4 years. They are all online at http://www.cs.wustl.edu/~schmidt/report-doc.html.

    You may surf and search the tao-users mailing list archives.

    Training

    Doug Schmidt teaches a course at UCLA Extension. See http://www.cs.wustl.edu/~schmidt/UCLA.html for more details.

    OCI offers courses on CORBA programming with C++, CORBA programming with Java, Advanced CORBA programming using TAO, and programming with ACE. See http://www.objectcomputing.com/education/services/descrip/dist for more details on these and related courses.

    Tutorials

    You can build TAO and work through the online tutorials in $TAO_ROOT/docs.

  • What's the relationship between OCI's TAO and the DOC Group's TAO?

    OCI's Distribution of TAO is signified with a letter in the version number (e.g., TAO 1.3a, TAO 1.4a), whereas DOC Group release version numbers do not include a letter (e.g., TAO 1.4, TAO 1.5). OCI patch releases also indicate a patch level (e.g., TAO 1.4a_p12), whereas DOC Group beta kits indicate the beta number after a major release (e.g., TAO 1.5.4).

    Each OCI release is derived from a DOC Group version (for example, TAO 1.4a was derived from TAO 1.4.3), but an OCI release does not correspond exactly to any DOC Group release.

    OCI seeks to maintain extremely stable, fully-tested, open source products backed by commercial support, training, consulting, and accompanied by extensive documentation and binaries on CD-ROM available for purchase. Many organizations desire a commercially-supported release of TAO as a basis for their mission critical applications.

    The DOC Group's primary focus is research and development rather than commercial support. Support is provided on a "best effort" basis through the public tao-users mailing list, and is often excellent. However, more "predictable" support is availble from OCI and other organizations.

    OCI selects a reasonably stable DOC Group release as the basis for each OCI distribution. OCI then builds and tests across over 50 combinations of hardware, operating systems, C++ compilers, and build flags. As bugs are encountered, they are fixed directly (and the fix is contributed back to DOC), fixed by integrating an existing DOC fix (depending on the severity and the degree of entanglement), or documented (if a fix is too involved to be accomplished without sponsorship).

    In addition, OCI applies various enhancements, sponsored by our customers. We also integrate these back into the DOC group repository.

    OCI also packages select binaries (custom builds are also available -- see {{site.baseurl}}/product/index.html) and makes them available for purchase on CD-ROM. Since OCI's distribution of TAO is still open source, OCI also distributes the source code and all patches free of charge (see {{site.baseurl}}/downloads).

    In OCI distributions, the original DOC Group ChangeLogs are preserved; OCI changes are documented in OCIChangeLog and OCIReleaseNotes.html files, included in the source code distribution. See, for example, the latest OCI TAO 1.4a Release Notes.

  • What's a PRF?

    "PRF" refers to the PROBLEM-REPORT-FORM, i.e., $ACE_ROOT/PROBLEM-REPORT-FORM. This boilerplate document is found in both DOC distributions and OCI distributions.

    The odds of getting questions answered, bugs fixed, etc., goes up significantly when you report problems using the PRF because it insures that developers and support personnel get the most commonly required information right away. Failure to use the PRF means that those folks have to spend valuable time (yours and theirs) having a conversation to get that information just to start debugging. Unless you've got a paid support contract, there's even a chance that nobody will answer!

    So, always use the PRF!

  • I want to ask a question about TAO; what can I do?

    See ACE+TAO Mailing lists for a full description of all the available ACE and TAO mailing lists. Please remember to use the Problem Report Form (See LINK:086:) when posting questions (and not just "problems").
  • With which OMG CORBA specifications is TAO compliant?

    Compliance, just like source code and the specifications themselves, is a moving target. Each version of TAO is compliant with various OMG CORBA specifications.

    Each version of the TAO Developer's Guide includes an appendix that discusses compliance of that version of TAO in detail. These appendices are available via {{site.baseurl}}/downloads/index.html.

  • How can I help extend TAO's functionality and add new features?

    TAO is open source and the development group welcomes code contributions. Active participation by users ensures a robust implementation. Please refer to the terms and conditions relating to software submissions in the ACE, TAO, CIAO, and CoSMIC copyright and licensing information: http://www.cs.wustl.edu/~schmidt/ACE-copying.html. In general, incorporation of your code into TAO results in it becoming "open" and the user community being protected by the ACE/TAO copyright and terms.

    OCI can also provide consulting and software engineering resources to help you add new functionality into TAO or to span additional platforms. We can also manage the inclusion of such code into the supported releases of new open source versions of TAO. We can provide anonymity if you wish to avoid exposing your technical strategies in public forums, where your competition may be watching. Contact sales@objectcomputing.com to discuss your project.

    Open source software can add immeasurably to the development of a rich infrastructure, and the provision of a high degree of application interoperability, from which we all may derive benefit. Read more about the benefits of open source at {{site.baseurl}}/product/benefit.html.

  • Why doesn't TAO support the BOA?

    The short answer is that the BOA (Basic Object Adapter) is no longer part of the CORBA specification.
    The BOA was removed because of its lack of portability and underspecification among various other shortcomings. The main argument for adding BOA support to TAO is migration of existing CORBA applications. Because the BOA is implemented differently by each vendor, porting to a TAO BOA would probably be the same amount of work as porting to the POA (which provides true cross-vendor portability). All in all, applications are probably better off making the transition to the POA.

  • Is the tao-users mailing list archived anywhere?

    Yes.

    You can find the tao-users archives on the web at http://groups.yahoo.com/group/tao-users/.

    The ace-users archive is available at http://groups.yahoo.com/group/ace-users/.

    ACE+TAO Mailing list info can be found at http://www.cs.wustl.edu/~schmidt/TAO-mail.html, which includes information about subscribing to the various mailing lists, including tao-users.

    Thanks to Irfan Pyarali for providing this information!

  • Can I use version X of TAO with version Y of ACE?

    Only if X and Y were the versions of TAO and ACE that were released together. For example, ACE 5.1/TAO 1.1 or ACE 5.1.12/TAO 1.1.12. There is no attempt to make the interface between ACE and TAO backward (or forward) compatible. That being said, you may be able to coerce mismatched versions to work together, but it is not something you really want to do.

Building Distributions of ACE and TAO (basic)

  • How do I obtain, configure, and build ACE and TAO on Windows with Visual C++?

    This FAQ provides basic instructions for installing and building ACE+TAO for Windows with Visual C++. ACE+TAO can also be used on other major modern operating systems, such as Linux, Solaris, AIX, and HP-UX, and some real-time and embedded operating systems, such as VxWorks, LynxOS, Timesys Linux, and Windows CE.
     Hardware Requirements
    
      - CPU: ACE+TAO can be configured to build on a variety of 32
        and 64 bit processors (Intel, AMD)
      - Memory: 512 MB (more memory improves compile speed)
      - Hard Drive Space: 256MB swap + 500 MB up to several GB
        free (depending upon how much you build)
    
    Operating System Requirements
    
      - Windows 2000, 2003, XP, or Vista
    
    C++ Compiler Requirements
    
      - Microsoft Visual C++ 7.1, 8, or 9
    
    Other Software Requirements
    
      - OCI's Distribution of TAO version 1.6a latest patch
        release or the latest release or micro release of ACE+TAO
        (see instructions below for obtaining and installing
        ACE+TAO)
      - WinZIP or similar tool for extracting software archives
      - ActiveState Perl v5.6.1 or newer (recommended, but not required)
    
    Obtaining and Installing ACE+TAO
    
      1. Download the latest release of OCI TAO 1.6a (with latest
         patches, if available) from:
    
         https://downloads.opendds.org/TAO-1.6a/
    
         or download the latest release or micro release of ACE+TAO from:
    
         http://download.dre.vanderbilt.edu/
    
      2. Extract the archive into a path with no spaces in the path
         name (e.g., C:\ACE_wrappers).
    
      3. Set ACE_ROOT, TAO_ROOT, and PATH environment variables.
    
         For example, if ACE+TAO are installed in C:\ACE_wrappers, the
         variables will look like this:
    
         ACE_ROOT=C:\ACE_wrappers
         TAO_ROOT=%ACE_ROOT%\TAO
         The PATH variable should contain these directories: %ACE_ROOT%\bin;%ACE_ROOT%\lib
    
      4. Create a file named config.h in %ACE_ROOT%\ace with the following
         contents:
    
         #include "ace/config-win32.h"
    
      5. Build the Debug or Release configuration of ACE+TAO using
         the solution file that matches your version of Visual
         C++.  For example, in OCI TAO 1.6a you will see the
         following solution files:
    
         %TAO_ROOT%\TAO_ACE.sln      (Visual C++ 7.1)
         %TAO_ROOT%\TAO_ACE_vc8.sln  (Visual C++ 8)
         %TAO_ROOT%\TAO_ACE_vc9.sln  (Visual C++ 9)
    
         The projects in the TAO_ACE solution build the ACE and
         TAO libraries, TAO IDL compiler, gperf, ORB services
         libraries and executables, and some common utilities.
         They do not include any examples, tests, or performance
         tests.  (Separate directories and solutions exist for
         them.) Libraries will be installed in %ACE_ROOT%\lib.
         Some executables will be installed in %ACE_ROOT%\bin,
         others (the ORB services executables) will be installed
         in their source directories.
    
      6. If you don't want to build all of the libraries and
         executables from the TAO_ACE solution, we recommend just
         building the Naming_Service project.
         It, and the projects on which it depends, includes most
         of the common ACE+TAO libraries that you need for
         developing your applications.
    
      7. If the solution file you need does not exist, you will need
         to generate it using MakeProjectCreator (MPC) (requires
         Perl as listed above) with the following commands:
    
         cd %TAO_ROOT%
         %ACE_ROOT%\bin\mwc.pl -type vc[version] TAO_ACE.mwc
    
         where [version] is "71", "8", or "9" for Visual C++ 7.1,
         8, or 9, respectively.
    
         More information on MPC is available here:
    
         http://www.objectcomputing.com/products/mpc
    
  • How do I obtain, configure, and build ACE and TAO on Linux?

    This FAQ provides basic instructions for installing and building ACE+TAO for Linux. ACE+TAO can also be used on other major modern operating systems, such as Windows, Solaris, AIX, and HP-UX, and some real-time and embedded operating systems, such as VxWorks, LynxOS, Timesys Linux, and Windows CE.
     Hardware Requirements
    
      - CPU: ACE+TAO can be configured to build on a variety of 32
        and 64 bit processors (Intel, AMD, PowerPC)
      - Memory: 512 MB (more memory improves compile speed)
      - Hard Drive Space: 256MB swap + 500 MB up to several GB
        free (depending upon how much you build)
    
    Operating System Requirements
    
      - Linux 2.6.x kernel
    
    C++ Compiler Requirements
    
      - gcc 3.3.x (or later)
    
    Other Software Requirements
    
      - OCI's Distribution of TAO version 1.6a latest patch
        release or the latest release or micro release of ACE+TAO
        (see instructions below for obtaining and installing
        ACE+TAO)
      - GNU gunzip and GNU tar for extracting software archives
      - GNU make
      - Perl v5.6.1 or newer (recommended, but not required)
    
    Obtaining and Installing OCI TAO
    
      1. Download the latest release of OCI TAO 1.6a from:
    
         https://downloads.opendds.org/TAO-1.6a/
    
         or download the latest release or micro release of ACE+TAO from:
    
         http://download.dre.vanderbilt.edu/
    
      2. Extract the archive into a path with no spaces in the path
         name (e.g., /opt/ACE_wrappers)
    
      3. Set ACE_ROOT, TAO_ROOT, PATH, and LD_LIBRARY_PATH environment
         variables.
    
         For example, if ACE+TAO are installed in /opt/ACE_wrappers,
         the variables will look like this:
    
         ACE_ROOT=/opt/ACE_wrappers
         TAO_ROOT=$ACE_ROOT/TAO
         PATH will include the directory $ACE_ROOT/bin
         LD_LIBRARY_PATH will include the directory $ACE_ROOT/lib
    
      4. Create a file named config.h in $ACE_ROOT/ace with the following
         contents:
    
         #include "ace/config-linux.h"
    
      5. Create a file named platform_macros.GNU in
         $ACE_ROOT/include/makeinclude with the following contents:
    
         debug=1     # (or debug=0)
         optimize=0  # (or optimize=1)
         include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU
    
      6. Build ACE+TAO using the following commands:
    
         cd $TAO_ROOT
         make
    
         The above commands will build the ACE and TAO libraries,
         TAO IDL compiler, gperf, ORB services libraries and
         executables, and some common utilities.  They will not
         build any examples, tests, or performance tests.
         (Separate directories and GNUmakefiles exist for them.)
         Libraries will be installed in $ACE_ROOT/lib.  Some
         executables will be installed in $ACE_ROOT/bin, others
         (the ORB services executables) will be installed in their
         source directories.
    
         Note that it is possible to distinguish builds by architecture
         using the $ARCH environment variable. if $ARCH is set, the libs
         will be installed in $ACE_ROOT/lib/$ARCH. If you are using $ARCH
         to control the target, the value must not contain spaces. For
         example, "Linux" or "x86_64" are acceptible but "Linux x86_64"
         is not.
    
      7. If there are no GNUmakefiles, you will need to generate them
         using MakeProjectCreator (MPC) (requires Perl as listed above)
         with the following commands:
    
         cd $TAO_ROOT
         $ACE_ROOT/bin/mwc.pl -type gnuace TAO_ACE.mwc
    
         More information on MPC is available here:
    
         http://www.objectcomputing.com/products/mpc
    
  • How do I generate static project files?

    If you have Perl installed, you can use the Makefile, Project, and Workspace Creator (MPC) to generate them yourself. The steps below, while they assume a UNIX platform, can be used (with minor modifications) on any general purpose platform.

    1. Set the MPC_ROOT environment variable to point to the MPC package location. OCI's TAO release contains the MPC package at $ACE_ROOT/MPC.

      % export MPC_ROOT=<complete path to MPC package>

    2. Set the ACE_ROOT environment variable to the root of your ACE+TAO code base and execute the following commands to generate static project files:

      % cd $ACE_ROOT/TAO
      % $ACE_ROOT/bin/mwc.pl -type gnuace -static -name_modifier *_Static TAO_ACE.mwc

      Substitute your build tool's type for gnuace (e.g., use -type vc71 for Visual C++ 7.1).
    The default configuration can be modified by customising the $ACE_ROOT/bin/MakeProjectCreator/config/default.features file. Use the $ACE_ROOT/bin/MakeProjectCreator/config/global.features file as a template.

    Example: The following will generate static project files for the Visual C++ 7.1 compiler on Windows:

    % $ACE_ROOT/bin/mwc.pl -type vc71 -static -name_modifier *_Static TAO_ACE.mwc

    On UNIX machines you will need to turn on the static_libs_only flag in $ACE_ROOT/include/makeinclude/platform_macros.GNU to build static libraries.
  • How can I build debug applications with non-debug libraries?

    During development, you will normally want to build your application code with debugging enabled. However, you may be using non-debug versions of the ACE, TAO, and CIAO libraries. Depending upon your platform and development environment, special care must be taken to make sure your debug-enabled application can link against non-debug ACE, TAO, and CIAO libraries.

    On platforms that use GNU Make, all you have to do to enable debugging in your application is set the debug build flag to 1 when you build your application code. You can do this by setting debug=1 on the make command line, as follows:
     make debug=1 
    Or, you can set debug=1 in your platform_macros.GNU file when you build your application. Note: If you have debug=1 in platform_macros.GNU when you build the ACE, TAO, and CIAO libraries, they will be built with debugging enabled, too.

    On some platforms, such as Windows with Visual C++, the ACE, TAO, and CIAO library names may have a modifier appended to the library name to indicate whether it was built with a debug, static, MFC, or some other configuration. For example, in a debug build, the name of the ACE shared library will be ACEd.dll, whereas in a non-debug (release) build, the name of the ACE shared library will be ACE.dll.

    On these platforms, if you build your application with a debug configuration, and you are using project files generated by MPC, the linker will, by default, look for libraries with the "d" debug modifier appended to the library name. If you are building your debug application against non-debug libraries, you need to tell the linker to look for the unmodified library names. You can do this by directly editing the project settings (e.g., to remove the "d" from the library names). Or, you can use the -value_template MPC option to override the default definition of the library modifier when you generate your project files.

    For example, suppose your application's MPC workspace file is MyApp.mwc and suppose you are using Visual C++ 7.1. If you want to build your application against the same set of non-debug ACE, TAO, and CIAO libraries, regardless of whether you build the debug or release configuration, you can use the following command to generate your application's project and solution files:
     $ACE_ROOT/bin/mwc.pl -type vc71 -value_template lib_modifier= 
    The -value_template option in the above command sets the value of the lib_modifier template variable to an empty string, which causes no modifier to be added to the library names with which your application will link, regardless of which configuration (debug or release) you build.

    Watch out for build problems if you have any settings in your config.h file that depend upon having debugging enabled, for example:
     #if defined(_DEBUG) #undef __ACE_INLINE__ #endif 
    For more information on MPC, see the MPC documentation and the MPC FAQ:

    https://downloads.opendds.org/MPC
    http://www.objectcomputing.com/products/mpc/faq.html
  • GPERF is licensed as GPL2. Will that impact my application?

    No. TAO_IDL simply "fork/execs" a gperf process to generate the hash function, so it doesn't contain any GPL'd code internally, and hence is not a derived work in the GPL sense. (Thanks to Doug Schmidt) There are no other libraries in TAO that use GPERF code, nor any other GPL code. Neither is the generated code affected by the GPL.

OCI-Specific Issues

  • What's the advantage to buying OCI's Distribution of TAO?

    Depending upon your circumstances, there may be several advantages to buying OCI's Distribtution of TAO rather than closely tracking the beta source code kits:

    • Stability: OCI's Distribution of TAO is based on a stable, tested, and supported release of TAO. If you need a solid, consistent version of TAO on which to base your product or project, this is the one for you. If you need to stay abreast of new research directions or want to try out the latest features, you can still obtain TAO beta kits in source code form by visiting http://download.dre.vanderbilt.edu/.
    • Time Savings: Rather than downloading source code and building it yourself, OCI can provide prebuilt binaries for your specific platform, as part of our professional services. This can save you many hours of work. We regularly build and test across several platforms, operating systems, and compilers, in several different configurations, so we are well positioned to help you with your specific build.
    • Documentation: Using OCI's Distribution of TAO is easy with OCI's TAO Developer's Guide, available for complimentary download from https://objectcomputing.com/products/tao. In addition to the documentation set, the latest release notes are available directly in the source code distribution in $ACE_ROOT/OCIReleaseNotes.html.
    • Frequently Asked Questions: OCI maintains a list of frequently asked questions about TAO. This list is updated regularly by our staff of distributed object computing technology engineers to provide answers to common questions about using TAO. Anyone in the TAO user community can contribute questions (and answers) to the FAQ. Check it first to see if your question has been asked before. The FAQ is located at https://objectcomputing.github.io/OCITAO/support/faq.html
    • Professional Support: If you need further support, beyond installation issues or frequently asked questions, such as object technology training, consulting, mentoring, or application development, OCI has several service offerings for you. Visit http://www.objectcomputing.com for more information.

  • Does the OCI documentation set include the CD, too?

    No, it does not. The documentation set only includes OCI's own TAO Developer's Guide.
    CDs containing prebuilt versions of TAO for multiple platforms are available separately.
  • If I install TAO from the OCI CD set, do I need to build it?

    In addition to the full source code for ACE and TAO, the OCI CD set includes pre-built libraries for ACE, TAO, and TAO's CORBA services, plus executables for TAO's IDL compiler, gperf, and servers for the various services.

    The CD set contains these pre-built components for many popular platforms, operating systems, and C++ compilers.

    In addition, the builds on the CD set include more than one build configuration (i.e., debug on or off, native C++ exception support on or off).

    Note that the CD set does not include pre-built binaries of the various tests, performance tests, and examples that come with ACE and TAO, but the full source code for them is there.

    So, if you install TAO from the OCI CD set for one of the existing platform / operating system / compiler combinations, you can get started writing, building, and running your own applications that use TAO right away.

    Of course, since you have the full source code, you can custom build it yourself (e.g., for a particular platform, operating system, compiler, or configuration which is not present on the CD).

  • Are the Table of Contents and Index for the TAO Developer's Guide available on-line?

    Yes.

    The Table of Contents and Index for OCI's TAO Developer's Guide are available in PDF form via:

    {{site.baseurl}}/downloads/index.html

    Just follow the appropriate links to download the files you want.

  • Is it possible to install debug and release versions of TAO on the same Windows machine?

    It is possible to install both debug and release versions of TAO on one Windows machine by selecting a different installation directory for each installation and setting $ACE_ROOT and $TAO_ROOT appropriately. More efficienty, the debug and release versions of TAO can be installed in the same directory since the different versions of the libraries have slightly different names.
  • Why is the TAOd.dll library I install from OCI's CD so large?

    The DLLs on the CD include all the information you need to debug TAO applications. This information is normally stored by Visual C++ in .pdb files. Our builds store them in the .dll in a location independent manner (using the C7 compatible option for the debug information). This allows you to step into TAO code in the Visual C++ debugger.

    If you desire a smaller set of libraries, either install the release versions of the CD or rebuild the debug libraries with the default debug configuration.

  • How do I get support from OCI?

    You're always welcome to send a question. However, the disposition of your request depends upon whether or not you have a technical support contract with OCI:
    • If you have a technical support contract with OCI, someone will begin addressing the issue and will follow up with you according to the provisions outlined in your support contract.
    • If you do not have a technical support contract with OCI, someone will still review the support request and may get back to you, but we cannot guarantee that we will have time to work on the problem without a support contract.
    If you would like to open a technical support contract with OCI, please contact our sales staff at sales@objectcomputing.com or call +1.314.579.0066 extension 206. Please consult {{site.baseurl}}/support for a description of the TAO support model.
  • Which platforms (hardware/OS combinations) are supported by OCI's Distribution of TAO?

    A full list of platforms (and other support details) is available at {{site.baseurl}}/support/index.html.

ORB Services

  • I'm having weird problems with the Naming Service. How can I solve them?

    More than likely you're having problems related to multicast discovery of the Naming Service. Multicast was the default mechanism for finding the Naming Service in older versions of TAO. Symptoms range anywhere from a client not being able to find the Naming Service at all, to finding it sometimes, to just completely bizarre and inexplicable behavior.

    So, before you do anything, try it all again, but this time turn off multicast discovery. See LINK:004:.

  • How do I locate the Naming Service without resorting to multicast discovery?

    Here are some common ways to use the -ORBInitRef option to locate the Naming Service (where bart is just an example host name):

    # Store the IOR of the Naming Service's root Naming Context in a file:

       Naming_Service -m 0 -o /tmp/ns.ior
       client -ORBInitRef NameService=file:///tmp/ns.ior
    # Specify an IIOP endpoint when you start the Naming Service:
       Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809
       client -ORBInitRef NameService=corbaloc:iiop:bart:2809/NameService

    You can also use the NameServiceIOR environment variable to achieve the same effect. Here, we show what it might look like on a UNIX or UNIX-like system using the bash shell:

      Naming_Service -m 0 -ORBListenEndpoints iiop://bart:2809
      export NameServiceIOR=corbaloc:iiop:bart:2809/NameService
    Now, when your client calls resolve_initial_references("NameService"), no multicast will be performed. The -m 0 option turns multicast off in the Naming_Service server. This is the default in TAO versions 1.1.17 and later. Earlier versions defaulted to multicast enabled in the server.
  • Why is multicast discovery of the Naming Service failing?

    There can be a myriad of reasons, many related to network or OS-level issues rather than TAO. Try turning on -ORBDebugLevel 5 to get some sense of what might be happening internally.

    If you're using Windows, check out LINK:107: and see if it applies.

  • Is the Naming Service server's object reference "persistent?"

    Yes, TAO's implementation of the OMG Naming Service always creates a persistent IOR for the root Naming Context. That is to say, it creates the object reference in a POA that has the PERSISTENT life span policy. Thus, you can use the IOR across invocations of the Naming Service provided that the service always starts up on the endpoint used when creating the original reference.

    Use the -ORBListenEndpoints option to specify that the server should start on a specific endpoint, e.g.,

      Naming_Service -ORBListenEndpoints iiop://bart:2809
    The general form is:
      Naming_Service -ORBListenEndpoints iiop://name_server_host:name_server_port
    For more detailed information on using the -ORBListenEndpoints option, see the TAO Developer's Guide

    For more information on direct binding of persistent object references, see Henning's and Vinoski's Advanced CORBA Programming with C++, 14.3.2.

  • How do I keep Cos Event Service consumers from blocking suppliers?

    By default, the COS event channel delivers an event to a consumer using the same thread that received it from the supplier. When suppliers publish or emit events, they do so using a two-way invocation. When the event channel delivers an event, it also uses a two-way invocation. Since these are both two-way calls, and the delivery invocation is initiated during the publishing invocation, this causes the supplier to block (waiting for the response to its two-way publication invocation) while the consumers process the event.
    This behavior can be avoided by directing the event channel to use a separate dispatching thread for the push to the consumers. This is accomplished differently depending on which COS EC is being used.
    When using the "native" COS EC, the -CECDispatching option can be used to change the dispatching strategy. A dispatching strategy of "mt" (multithreaded) will start a second thread and use it for the push calls to the consumer. Placing the following option in the service configurator file does the trick:
       static CEC_Factory "-CECDispatching mt"
    For example, if this line was placed in ec.conf, then the event channel server can be started with the following command:
       CosEvent_Service_Native -ORBSvcConf ec.conf
    The -CECDispatchingThreads option is used to control the number of threads used for consumer deliveries.
    When using the COS EC that wraps the RTEC (which is the only COS EC in older versions of TAO), the same effect can be accomplished by using the analogous options on the RTEC (-ECDispathing and -ECDispatchingThreads on the EC_Factory).
    For more information about these and other event channel options, see the TAO Developer's Guide, 14.8 and the online documentation at $TAO_ROOT/docs/cec_options.html and $TAO_ROOT/docs/ec_options.html.
  • Why does my event channel get so slow when consumers die?

    By default the event channels (Cos and RTEC) in TAO continue to attempt to push new events at consumers even after previous pushes to that consumer have failed. If a particular consumer is destroyed without disconnecting from the event channel, then all subsequent pushes by the corresponding supplier proxy will fail. Since each of these require the ORB to timeout, they can drastically affect the throughput of the EC.

    You can modify this behavior via the -ECSupplierControl and -ECConsumerControl options. The consumer control option sets the strategy used to deal with ill-behaved consumers. Put the following in a service configurator option file (ec.conf):

       static EC_Factory "-ECConsumerControl reactive"

    This sets the control strategy for the consumers to reactive. Now start the event channel process with this configuration:

       $TAO_ROOT/orbsvcs/Event_Service -ORBSvcConf ec.conf

    Any failed attempts to communicate with a consumer result in the disconnection of that consumer (and its proxy) from the event channel. The reactive strategy also polls all the consumers periodically and disconnects them if they fail to respond. The default polling period is 5 seconds and can be set via the -ECConsumerControlPeriod option.

    The supplier control strategy (and associated polling period) works the same way with suppliers.

    The native Cos Event Channel has analogous options (-CECConsumerControl, -CECSupplierControl, -CECConsumerControlPeriod, and -CECSupplierControlPeriod).

  • Does TAO's CosEvent Service support Typed Events?

    Yes, as of TAO 1.3.4. See $TAO_ROOT/orbsvcs/examples/CosEC/TypedSimple for a simple example using Typed Events.
  • What is the difference between TAO's Real-Time Event Service and the OMG Notification Service?

    The Notification Service is an implementation of the OMG's Notification Service specification, which originally came out of the Telecommunications working group within the OMG. See http://www.omg.org/cgi-bin/doc?formal/2000-06-20 for the specification. The Notification Service is backwards compatible with the OMG Event Service.

    The Real-Time Event Service is TAO specific. It was developed prior to the adoption of the OMG Notification Service specification. The RT Event Service was designed to meet the real-time and quality of service needs of certain sponsors of the DOC group, but has applicability in a wide variety of domains.

    On the surface, the two services provide several similar features, though the specifics of their interfaces and implementations are quite different:

    • similar communications model
    • support for structured events
    • filtering of events
    • support for subscriptions
    • mechanisms for specifying QoS requirements
    • support for delivery of sequences of events

    In addition, the RT Event Service provides some features that are not part of the Notification Service, such as event channel federations, event correlation, suspension and resumption of consumer connections, and integration with a scheduling service.

    The RT Event Service is older and perhaps more "mature" in that it has been through multiple iterations of development and is in active use by many real world applications. However, the Notification Service is also quite good and since the Notification Service is based on an OMG specification, it may be a better choice for your application, depending upon your needs.

Security Service & SSLIOP

  • Is it built automatically or do I have to do something special?

    Security and SSLIOP are not built in a default configuration. You must add stuff to your platform_macros.GNU (see LINK:106:) as well as install additional software (see LINK:104:).
  • What additional software do I need to install?

    You'll need OpenSSL (http://www.openssl.org).

    In addition, you might need a way of getting good random numbers.

  • How do I build TAO to get security and SSLIOP?

  • Is it legal for me to have this? What sort of legalities are there in using this?

    First, we're software developers and not lawyers. We might be able to write good software, but it takes a mind far more twisted than ours to understand US Export regulations, especially on cryptography and security issues. Therefore, if you have concerns, you should consult your lawyer.

    That said, you might look at http://www.bis.doc.gov/Encryption/ for current information from the U.S. Government if you're under its jurisdiction.

  • How I can enter the certificate password using an API rather than requiring a user to type in the password?

    The ACE_SSL wrappers don't provide an API or wrapper method(s) to do this. However, you can set a password callback function by manually using the OpenSSL functions. For example, something like the following should work:
            SSL_CTX *ctx = ACE_SSL_Context::instance ()->context ();
    // SSL_CTX_set_default_passwd_cb() is from OpenSSL. SSL_CTX_set_default_passwd_cb (ctx, your_callback);
    where "your_callback" is a pointer to your PEM passwork callback function. See <openssl/ssl.h> and <openssl/pem.h> for the required callback function signature.
  • Why can't I make an SSLIOP connection using a DSA certificate?

    If you would like to create and use DSA certificates there are a couple of things that need to be done for it to work with SSLIOP. When using DSA certificates you need to specify DH parameters. You can do this by obtaining the SSL context before any connections are made using the ORB. This is TAO specific therefore not portable to other ORBs. First you need to obtain a set of DH parameters. You can either generate these at runtime ( which will take a very long time ), or generate them once with the openssl tool and append them to the end of your certificate.
      openssl tool: [Command Line]
           openssl gendh 512 >>cert.pem
    This will add 512-bit DH parameters to the end of the file cert.pem. After you have created these parameters you will need to load them in your application.
      #include "orbsvcs/SSLIOPC.h"
      #include "openssl/pem.h"
    // Open the file with the DH parameters FILE * fp = fopen ( "cert.pem", "r" );
    // Read in the DH parameters from the open file DH * dh_params = PEM_read_DHparams ( fp , NULL, NULL, NULL );
    // Obtain the SSL Context so we can set the DH parameters for it SSL_CTX * ssl_ctx = ACE_SSL_Context::instance()->context();
    // Set the DH Parameters for the SSL Context SSL_CTX_set_tmp_dh ( ssl_ctx , dh_params );
    This should be it. This sets the DH parameters needed to use a DSA certificate with SSLIOP. Please note that a greater degree of error checking should be done than what is provided in this code.
  • How can I use a non-security enabled Naming Service with a security (SSLIOP) enabled client?

    When security is enabled in a CORBA client's ORB, all invocations will be attempted using a secure connection. However, the Naming Service for example may not be set up to use security. Invocations on that Naming Service will result in a CORBA::INV_POLICY exception since the client is unable to make a secure/protected invocation on that non-security enabled Naming Service.
    To correct this problem, protected invocations via the Naming Service's object reference must be disabled. This is achieved by setting a policy override on the Naming Service's object reference like so:
      // Disable protection on Naming Service invocations.
    Security::QOP qop = Security::SecQOPNoProtection;
    CORBA::Any no_protection; no_protection <<= qop;
    // Create the Security::QOPPolicy. CORBA::Policy_var policy = orb->create_policy (Security::SecQOPPolicy, no_protection);
    CORBA::PolicyList policy_list (1); policy_list.length (1); policy_list[0] = CORBA::Policy::_duplicate (policy.in ());
    // Get a reference to Naming Context CORBA::Object_var obj = orb->resolve_initial_references ("NameService");
    // Create an object reference that uses plain IIOP (i.e. no // protection). CORBA::Object_var unprotected_obj = naming_context_object->_set_policy_overrides (policy_list, CORBA::SET_OVERRIDE);
    // Narrow to a CosNaming::NamingContext CosNaming::NamingContext_var naming_context = CosNaming::NamingContext::_narrow (unprotected_obj.in ());
    This is based on TAO's Secure_Invocation test client side code in $TAO_ROOT/orbsvcs/tests/Security/Secure_Invocation/client.cpp. (TAO 1.2 or better)
    The above policy override code is standard and should be portable to all ORBs that support the SecurityLevel2::QOPPolicy quality-of-protection client-side policy.
    Don't forget to include "orbsvcs/SecurityC.h" (this is TAO-specific) to pull in the Security QoP policy related constants and types.
  • How can I make access to some objects more secure than access to others?

    Use the Security service's AccessDecision interface. This is available in via TAO/orbsvcs/orbsvcs/SecurityLevel2.idl. An example of using this interface is provided in TAO/orbsvcs/Security/mixed_security_test.

    The AccessDecision interface gives the ability to weaken the security requirements for designated object references. Show here, its single operation is intended to be called from an interceptor, or perhaps from within a servant.

     module SecurityLevel2 {
      local interface AccessDecision {
    
    #   pragma version AccessDecision 1.8
    
        boolean access_allowed (
          in   SecurityLevel2::CredentialsList     cred_list,
          in   Object                              target,
          in   CORBA::Identifier                   operation_name,
          in   CORBA::Identifier                   target_interface_name
        );
      };
    }; 

    TAO also extends this interface in order to allow for runtime configuration of the supplied AccessDecision object, for adding or removing objects for consideration.

     module TAO {
      module SL2 {
        local interface AccessDecision : SecurityLevel2::AccessDecision
        {
          /* TAO-specific access_allowed that works around deficiencies in
             the SecurityLevel2::AccessDecision::access_allowed() operation. */
          // Parameter object_id should be PortableInterceptor::ObjectId, but
          // using that type would require including the PI_Forward.pidl file.
          // By using the real type, we can avoid that dependency.
          boolean access_allowed_ex (in ::CORBA::ORBid orb_id,
                                     in ::CORBA::OctetSeq adapter_id,
                                     in ::CORBA::OctetSeq object_id,
                                     in ::SecurityLevel2::CredentialsList cred_list,
                                     in ::CORBA::Identifier operation_name);
    
          /*! Default value returned when a reference is not in the list. */
          // Can't come up with a good name for this.
          attribute boolean default_decision;
    
          /*! Establish whether a particular object can be accessed via insecure
            means. */
          void add_object (in ::CORBA::ORBid orb_id,
                           in ::CORBA::OctetSeq adapter_id,
                           in ::CORBA::OctetSeq object_id,
                           in boolean allow_insecure_access);
          void remove_object (in ::CORBA::ORBid orb_id,
                              in ::CORBA::OctetSeq adapter_id,
                              in ::CORBA::OctetSeq object_id);
        };
      };
    }; 

    In addition to adding operations for adding or removing object references for consideration by the AccessDecision object, an extended access allowed operation is also provided, to work around a deficiency in comparing object references. For TAO, serialized object references cannot be used for comparison because they are produced using CDR encoding. This encoding uses padding bytes for alignment of multibyte values, and the padding bytes are uninitialized, meaning they will contain random data, and thus cannot be used when comparing two serialized object references.

    Typically, your application will initialize the AccessDecision object by supplying it with information used to unambiguously identify the object reference, and rely on the built-in interceptor to make the call to access_allowed. TAO's security interceptor, supplied as part of the TAO_Security library, will first check with the AccessDecision object to see if unrestricted access is allowed, and if not will then evaluate the request based on the regular secure access rules.

    It is possible to implement your own AccessDecision object to provide even greater control, such as restriction based on the content of the supplied credentials, and even on a per-operation level.

    To use the AccessDecision interface, you must first obtain a reference to the Level 2 Security Manager from the ORB. From that you get the AccessDecision, and finally narrow that to a TAO::SL2::AccessDecision reference.

     #include 
    int main (int argc, char *argv[]) {
      CORBA::ORB_var orb = ORB_init(argc,argv);
      CORBA::Object_var obj =
         orb->resolve_initial_references("SecurityLevel2:SecurityManager");
    
      SecurityLevel2::SecurityManager_var secmgr =
         SecurityLevel2::SecurityManager::_narrow (obj.in());
    
      SecurityLevel2::AccessDecision_var ad = sl2sm->access_decision ();
      TAO::SL2::AccessDecision_var tao_ad =
          TAO::SL2::AccessDecision::_narrow (ad.in ());
      //...
    

    At this point, you supply object references for consideration. It is best to do this when you are creating the references so that you don't have to keep track of the required information.

          PortableServer::ObjectId_var oid = rootpoa->servant_to_id (server2);
          CORBA::OctetSeq_var poaid = rootpoa->id();
          CORBA::String_var orbid = orb->id();
          sl2ad->add_object (orbid.in(), poaid.in(), oid.in(), true);
    

    At this point, you are ready to go, the AccessDecision::access_allowed operation effectively adds a -SSLNoProtection SSLIOP attribute only on those object references you added to the AccessDecision object.

Boostrapping and Discovery Mechanisms

  • Can I use resolve_initial_references() to directly bind to my own servers?

    Instead of binding object references with the Naming Service and requiring clients to resolve them by name, you can make it possible for clients to directly bind to objects using CORBA::ORB::resolve_initial_references(), the same mechanism used to bind to other important objects, such as the Naming Service.

    For example, suppose you have a server that provides a Bank object (let's call it "CORBABank"). Rather than binding this object by name in a naming context in the Naming Service, you would like clients to access it directly by simply calling

      orb->resolve_initial_references("CORBABank");
    

    There are several ways to accomplish this.

    1. Directly bind the object reference into the client ORB's list of references using an ORB initializer and the ORBInitInfo::register_initial_references() function.
    2. Use the client ORB's register_initial_reference() member function.
    3. Use the -ORBInitRef ORB initialization option on the client ORB

    The following steps describe one way to use the 3rd method described above.

    1. In the server, generate an IOR for the target object as usual.
    2. Give the CORBA Object a simple object key by registering its IOR in the server ORB's IOR Table (See LINK:073: for details)
    3. Start the server listening on a particular endpoint using the -ORBListenEndpoints option.
    4. Start the client with the -ORBInitRef option and assign the service name to the simple corbaloc-style reference of the CORBA Object.
    5. In the client, call resolve_initial_references() and pass it the service name.

    The combination of the simple object key and the fixed endpoint allows us to reference the object via a corbaloc-style reference in the -ORBInitRef option.

    For example, we can start our processes as follows:

      server -ORBListenEndpoints iiop://bart:10200
      client -ORBInitRef CORBABank=corbaloc:iiop:bart:10200/BankObject
    

    Where BankObject is the simple object key assigned to the CORBA object in the server.

    Now, on the client side, we can use resolve_initial_references("CORBABank") to directly bind to the Bank object living inside the Bank server. For example:

      // Initialize the ORB.
      CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    
      // Get a reference to the Bank using resolve_initial_references().
      CORBA::Object_var obj = orb->resolve_initial_references("CORBABank");
      Bank_var bank = Bank::_narrow(object.in());
      if (CORBA::is_nil(bank.in())) {
        cerr << "Bank::_narrow() failed!" << endl;
        return 1;
      }
    
      // Use the Bank's object reference like you normally would...
    

    Note that on older versions of TAO (before 1.1.10) the object reference format is slightly different:

      client -ORBInitRef CORBABank=iioploc://bart:10200/BankObject
    

  • How do I use a "corbaloc" object reference with a TAO server?

    Note: The corbaloc style object reference was added to the CORBA standard via the Interoperable Naming Service specification. For more information on "corbaloc", see the CORBA 2.3.1 (or later) specification, section 13.6.6.

    TAO added support for corbaloc references in version 1.1.10. Prior to that, TAO supported an earlier version of the specification that used the iioploc format. You can use corbaloc references to contact servers built with any version of TAO (assuming the client ORB supports them).

    To simplify use if corbaloc object references, you can register your CORBA object in the server ORB's IOR table so it can be located via a simple object key. To bind an object reference to this table in current versions of TAO (1.1.10 and later):

      // Turn your object reference into an IOR string 
      CORBA::String_var ior_string = orb->object_to_string(obj.in());
    
      // Get a reference to the IOR Table 
      CORBA::Object_var tobj = orb->resolve_initial_references("IORTable");
      IORTable::Table_var table = IORTable::Table::_narrow(tobj.in());
    
      // Bind your stringified IOR in the IOR Table 
      table->bind("CORBABank", ior_string.in());
    
    You will also need to #include "tao/IORTable/IORTable.h" and link with the TAO_IORTable library.

    In older versions of TAO (1.1.9 and prior) this binding is accomplished via the following code:

      // Add our Bank object to the ORB's IOR table (TAO specific).
      orb->_tao_add_to_IOR_table( "CORBABank", obj.in() );
    

    Both of these techniques make it possible for corbaloc-style object references to locate the specified CORBA object via a simple object key ("CORBABank"). The Bank's object reference doesn't necessarily have to be a persistent object reference, but it can be. For more information on persistent object references, see LINK:094:.

    When we run the TAO server, we must ensure that it listens on a host and port that are known to the client. We use TAO's -ORBListenEndpoints command-line option to do this. The format of -ORBListenEndpoints is

      -ORBListenEndpoints iiop://host:port
    
    For example, if I'm running my server on host "myhost", listening on port 11019:
      server -ORBListenEndpoints iiop://myhost:11019
    
    When running the client, we'll use a "corbaloc" object reference. The format of the "corbaloc" object reference is
      corbaloc:protocol:host:port/ObjectKey
    
    For example:
      corbaloc:iiop:myhost:11019/CORBABank
    
    connects to the server on host "myhost" at port 11019, and finds the object reference in that server corresponding to the "CORBABank" key. This object reference can be passed to ORB::string_to_object() and then is used like any other object reference.
  • How do I make my object references persistent?

    In CORBA terminology a transient object reference is one that is only good for the lifetime of a given server's execution. If you run a server, distribute a transient reference to a client, and then kill the server, then the object reference is now useless (even if the server is restarted). A persistent reference allows you continue to use the reference even if the server is restarted.
    In order to make your object references persistent you must do the following in your server:
    1. Create a child POA with the PERSISTENT and USER_ID policies.
    2. Create an ObjectId for each servant using PortableServer::string_to_ObjectId().
    3. Activate the object in the child POA using activate_object_with_id().
    4. Start the server listening on a particular endpoint using the -ORBListenEndpoints option.
    All of this is standard CORBA except for step 4, which requires an ORB-specific option. An alternative to step 4 is to use the Implementation Repository.
    For example:
      // Initialize the ORB.
      CORBA::ORB_var orb = CORBA::ORB_init(argc, argv);
    
      // Obtain an object reference for the root POA.
      CORBA::Object_var obj = orb->resolve_initial_references("RootPOA");
      PortableServer::POA_var rpoa = PortableServer::POA::_narrow(obj);
    
      // Create a policy list for our child POA.
      CORBA::PolicyList bankPolicies;
    
      // Create the policies for our child POA:
      //   LifespanPolicy: PERSISTENT
      //   IdAssignmentPolicy: USER_ID
      pols.length(2);
      pols[0] = rpoa->create_lifespan_policy(PortableServer::PERSISTENT);
      pols[1] = rpoa->create_id_assignment_policy(PortableServer::USER_ID);
    
      // Get the Root POA's POA Manager so it can manage our child POA
      PortableServer::POAManager_var poa_mgr = rpoa->the_POAManager();
    
      // Create the child POA.
      PortableServer::POA_var bank_poa =
        rpoa->create_POA("BankPOA", poa_mgr, pols);
    
      // Destroy the POA policies (create_POA() makes a copy).
      pols[0]->destroy();
      pols[1]->destroy();
    
      // Create a Bank servant object and activate it with the POA.
      Bank_i* bankServant = new Bank_i();
    
      // Explicitly activate the Bank servant.  We will use the string
      // "CORBABank" to generate an ObjectId for the bank.
      CORBA::String_var bankIdString = CORBA::string_dup("CORBABank");
      PortableServer::ObjectId_var bankId =
        PortableServer::string_to_ObjectId(bankIdString.in());
      bank_poa->activate_object_with_id(bankId, bankServant);
      obj = bank_poa->id_to_reference(bankId.in());
    
      // Activate the POAs.
      poa_mgr->activate();
    
      // Handle requests from clients.
      orb->run();
    

    Since the Bank's object reference is a persistent IOR, when we invoke the Bank's server, we need to specify a particular endpoint for the ORB. For example:

      BankServer -ORBListenEndpoints iiop://bart:10200
    

    Now, any clients that receive these object references can use them between different runs of the server. Note, that you still need to manually restart the server, unless you use the Implementation Repository.

  • Using the Naming Service

    The Naming Service is a common boostrapping/discovery mechanism. The following FAQ's address the naming service: LINK:115:, LINK:004:, LINK:108:, LINK:010:

Runtime Configuration

  • How do I get a TAO server to use IIOP v1.0 or v1.1?

    You must use the -ORBListenEndpoints option. For further details, please refer to the TAO Developer's Guide, the chapter on "ORB Initialization Options." Alternately refer to $TAO_ROOT/docs/Options.html.

    The short answer is:

    -ORBListenEndpoints iiop://V.v@[hostname:[port]]

    The V.v@ portion of this syntax informs the server to use a specific major and minor version of the specified protocol. For example, to force a server to use IIOP v1.1 (instead of the default v1.2) on a host named "barney" at port 22000:

    -ORBListenEndpoints iiop://1.1@barney:22000

    If you always want to force use of IIOP 1.0 or 1.1, you can set the following macro values and rebuild TAO (and your application):

    #define TAO_DEF_GIOP_MAJOR 1
    #define TAO_DEF_GIOP_MINOR 0 [or 1]

    These macros are typically set in $TAO_ROOT/tao/orbconf.h or $ACE_ROOT/ace/config.h.
    Correction to the "-ORBListenEndpoints" syntax. It should be:
    -ORBListenEndpoints iiop://1.0@[host][:port]
    The hostname is not always required.

  • Why is my "client" thread dispatching requests?

    By default, TAO attempts to efficiently use all the threads that are given to it. This includes "client" threads that have sent a request and are waiting for a reply from the server. While waiting, these threads enter the normal thread pool reactor event loop. This means that any incoming requests (assuming that the process is also a server) may be dispatched using that thread. Such a situation is referred to as a "nested upcall".

    This has a couple of side effects that surpise many people. First, it is possible for even a single threaded server to process more than one request at the same time. Second, if you try to allocate threads exclusively as "server" threads and "client" threads, the ORB will pay no attention to your idea of what these threads are and dispatch requests on both.

    Why is this the default behavior of TAO? Mainly because nested upcalls avoid many potential deadlock situations. One example is a simple callback operation with a single threaded client. When the client sends a request to the server, the server sends a callback request back to the client. If the client's only thread is waiting for the reply and not dispatching incoming requests, then a deadlock is now in place. The default behavior allows the client ORB to process the callback request and send a reply to the server which frees the server ORB to send its reply back to the client.

    There however are situations where you may wish to prevent nested upcalls in your application. Some common reasons are:

    • Real-time applications which impose strict response times.
    • Resource limitations which impose concurrency limitations.
    • Short response time. The response will be buffered until the nested upcall unwinds.
    • Recursive nested upcalls may lead to unbounded stack growth, which will eventually crash the application.

    See entry How can I prevent nested upcalls in my application? for techniques to prevent nested upcalls.
  • How can I prevent nested upcalls in my application?

    As discussed in entry Why is my "client" thread dispatching requests? there are situations when we may want to disable nested upcalls in our application. There are several techniques available to prevent nested upcalls. These are:

  • The RW wait strategy is the most popular and probably the easiest mechanism to prevent nested upcalls. You can modify the default client wait strategy via the -ORBWaitStrategy (formerly known as the -ORBClientConnectionHandler) service configurator option.Specifying an "rw" wait strategy causes threads waiting for replies to not enter the normal event loop and instead block for their pending reply. This keeps the ORB from dispatching incoming requests on your "client" threads. One side effect of this option is that your client is now more susceptible to deadlocks as discussed in Why is my "client" thread dispatching requests?. Here are the required directives (each directive should appear on one line):

     static Client_Strategy_Factory "-ORBWaitStrategy rw -ORBTransportMuxStrategy exclusive
    			        -ORBConnectStrategy blocked -ORBConnectionHandlerCleanup 1"
    
    static Resource_Factory "-ORBFlushingStrategy blocking" 

    Note that you should always set the -ORBTransportMuxStrategy to exclusive, the -ORBConnectStrategy to blocked, the -ORBFlushingStrategy to blocking and the -ORBConnectionHandlerCleanup to 1 when using the rw wait strategy.

    Also note that -ORBConnectionHandlerCleanup is not available in versions of TAO prior to 1.4a_p11.

    The reason for using exclusive transport multiplexing is that you must not allow another request to be sent over a connection if that connection is already being used by another thread that is waiting for a reply. The blocking connect and flushing strategies are required because the event handler for a connection used to send a request is not registered with the ORB's Reactor. The Connection Handler Cleanup strategy needs to be enabled to properly cleanup server side connection closure.

    Finally, it is important when using -ORBConnectionHandlerCleanup that the ORB event loop be run, at least periodically. The connection handler cleanup option works by using some internal reactor-based messaging. If this option is used and the ORB's event loop is not run, the application will eventually deadlock.

  • The Two-ORB technique relies upon all outbound invocations being made from a designated 'client ORB'. This will prevent the client threads from entering the 'server ORB' thread-pool and hence don't get dispatched for nested upcalls. To make sure invocations on object references always go through the "client" ORB, just make sure those object references are always demarshalled using the client ORB. This can get tricky. For example, if you receive an IOR for a callback object as an in parameter to an operation, it will have been demarshalled through the "server" ORB (the one that received the request). To force the IOR to be demarshalled via the "client" ORB, you have to play some trick like this:
     // Assume the callback's IOR is in a Callback_var called cb.
    // First, "remarshal" the callback IOR using the "server" ORB. CORBA::String_var cbstr =
        server_orb->object_to_string(cb.in());
    
    // Then, demarshal it using the "client" ORB. CORBA::Object_var new_ior =
        client_orb->string_to_object(cbstr.in());
    
    // Finally, narrow it to the derived interface type // (can reuse cb). cb = Callback::_narrow(new_ior.in()); 

    Now, when your application makes an invocation on the callback IOR, it will be sent via the "client" ORB, where it cannot be dispatched for nested upcalls.

    Note: Both Two-ORB and RW wait strategy are incompatible with BiDirectional GIOP.

  • What's the recommended configuration when using thread-per-connection?

    If you wish to use the thread-per-connection server-side concurrency model, a few other settings should also be present in your svc.conf file. Below is an example of this (each directive should appear on one line):
     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" 

    Note that -ORBConnectionHandlerCleanup is not available in versions of TAO prior to 1.4a_p11.
    The rationale behind these settings is as follows: in thread-per-connection a thread is dedicated to servicing requests that come in on a given connection. In order to keep this thread dedicated to its connection, we need to prevent the thread from entering the reactor or the leader-follows pool even in the event that the thread attempts to make a request on a remote object (see the Client_Strategy_Factory settings) or cannot write a large reply back to the socket all at once (the -ORBFlushingStrategy setting). This is closely related to the use of the RW wait strategy in order to prevent nested upcalls.
  • How can I have some objects available to one interface and the rest available on another?

    There are two key techniques you can use in this situation. You can use multiple ORBs, or you can use a single ORB and use the TAO-specific endpoint policy to filter endpoints on a per-POA basis.

    The two ORB approach works by passing separate endpoint collections defined with "-ORBEndpoint " to the different ORB_init calls used to initialize each ORB. This way, each ORB will listen their own endpoints and their POAs will only produce object references containing the endpoints associated with the ORB. The trade-off is that each ORB must run its own event loop, and each ORB must create its own root POA along with other resources.

    The endpoint policy approach allows you to have a process with a single ORB, and thus a single event loop and a single POA hierarchy, and still be able to have some POAs create object references containing a subset of the endpoints owned by the ORB. To see an example of the endpoint policy in action, look at TAO/tests/POA/EndpointPolicy.

    The endpoint policy implementation is stored in libTAO_EndpointPolicy. If you are using MPC to manage your build environment, have your server project inherit the "endpointpolicy" base project. Somewhere in your application code, you must #include "tao/EndpointPolicy/EndpointPolicy.h". The endpoint policy is initialized using protocol-specific valuetype containers. For each protocol you use in your application, you must also include the definition for the endpoint value. For example, use #include "tao/EndpointPolicy/IIOPEndpointValue_i.h" to include the IIOP-specific endpoint valuetype definition.

    The policy value for the endpoint policy is a list of endpoints. This way you may supply more than one endpoint value, even for different protocols, to the same endpoint policy. The constructor for IIOP-specific endpoint values takes a hostname and a port number.

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

    Endpoint policy instances are created the way any other custom policy might be, using the ORB's create_policy() operation.

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

    Unlike other POA related policies, this policy is applied to a POA manager. This is done via the POAManagerFactory interface.

      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);
    

    You then use this POAManager when you create POA instances. This POA manager is also the one on which you call activate to set all the related POAs to the active state.

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

    At this point any object references created by the "goodPOA" will contain only the endpoints specified on the list given to the "goodPOAManager".

    Important Note: The endpoint policy works to select endpoints that were previously passed to the ORB with the -ORBEndpoint or -ORBListenPoints ORB_init options. If you supply any endpoint values to the policy that do not match any of the ORB's endpoints, this by itself will not cause a failure, but that endpoint will be included in any object references. If none of the endpoint values given to the policy match the endpoints known to the ORB, the POA will throw an exception when attempting to create an object reference.

  • Why do I get this: ACE_DLL::open failed for TAO_Codeset?

    Codeset negotiation is an optional feature for TAO. It is implemented in a separate shared library, libTAO_Codeset.so, or TAO_Codeset.dll on Windows. Typically, TAO is not explicitly linked to the codeset library, rather it relies on the ACE Service Configuration framework to load the library for it.

    The error in question is reported when ACE cannot find the Codeset library in the LD_LIBRARY_PATH, or the runtime PATH on Windows. While most error or warning reports such as the one in question are guarded by a log-level test, this one is not, because the code in question is often used in static initializers, which are called before a log-level determination can be made.

  • Will TAO run without linking TAO_Codeset?

    Yes. However it will not participate in Codeset negotiate with other ORBs. If you are in a mixed environment where you are mixing, say, Unicode, UTF-8, or various Asian codesets, you will have problems with character interchange.
  • I'm not interested in using Codeset Negotiation, how can I disable it?

    You may disable the codeset negotiation feature completely by passing -ORBNegotiateCodesets 0 to ORB_init. When this is done, the TAO_Codeset library is not loaded, thus saving the memory and messaging overhead of codeset negotiation.

    TAO may also be built with codeset negotiation off by default. This is done by editing ACE_wrappers/ace/config.h and adding
    #define TAO_NEGOTIATE_CODESETS 0

    This will set the internal default to not load the codeset library, but this can be overridden by supplying -ORBNegotiateCodesets 1 to ORB_init.

  • I'm building a statically linked application and want to statically link the codeset library.

    This may be done via MPC. Edit $ACE_ROOT/bin/MakeProjectCreator/config/default.features file to add the line:
    negotiate_codesets = 1

    This will explicitly add TAO_Codeset to the link line of your application. Somewhere within the body of your code, you must also add #include "tao/Codeset/Codeset_Factory.h"

  • 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:

      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.