## Table of Contents

- Current Status
- Known Issues
- Ongoing work
- Future Work
- Completed Work

# ORB & ORB Core

Point of contact: Irfan Pyarali

Last Update: 2000/11/18 17:50:19

### Current status:

- We are fully compliant with OMG 2.2 / 2.3 spec.

Back to TOC

### Known issues:

- When using the thread-per-connection concurrency model, if some client leave the socket connection open without sending any request, the server will crash on NT. This is because we are doing a blocking recv when a server connection handler acts as an active object, and the recv won't break out until the process gets kill by the OS. This is especially a problem on NT because on shutdown, NT close down the socket service, which cause the blocking recv to unblock at which point, these threads try to access the already destroyed ORB resources. A temporary workaround is to close the sockets when the ORB is shutting down. But this is not portable and only works on NT.

- Object references for objects dynamically created within a server may not have proper host. When an object is dynamically created and its object reference returned, it simply has to "guess" at the host information that is returned in the IIOP Profile. Currently, it guesses using the host name, which is a reasonable guess in most cases. However, if there are multiple interfaces on a machine and they have different host names, it is possible that the desired effect will not be realized, i.e., the connection to that new object may use a different interface from the original object. Currently the only way to change this is to use the -ORBEndpoint option to manually specify that dynamically-created objects bind to a specific interface so that their IIOP Profile has the desired hostname. A more desirable fix is being investigated.

Back to TOC

### Ongoing Work:

- Trying to figure out a better resource management scheme. Resouces here include ORB, POA, connections, profiles.... that provide services for CORBA invocations.

  [STATUS]: The current version keeps very few objects managed by the resource factory. Most are ORB specific. It seems like the correct implementation is to make the few remaining resources (such as the Reactor) a per-ORB-per-thread entity.

- Support new concurrency models, e.g., Thread-per-Request, etc..

- Robustness improvements to connection cache so that it will purge old connections when there are no more slots or sockets are available.

  [STATUS]: The current version does go a long way to purge old connections. However, all socket creation points are not covered and acceptor-side sockets are not purged.

Back to TOC

### Future work:

- Performance optimizations, such as:

1. Replace all uses of `new` and `delete` with allocators that can be put into TSS. The main motivation for this is to eliminate lock contention when multiple threads need to allocate/deallocate memory, however it might also be possible to substitute an allocator better-tuned to an application's specific usage.

- Internal restructuring:

1. Create some sort of internal "request" object which carries enough context to suport deferred method invocation such as one might find in the thread-pool approach or wherever queuing might occur.

- Documentation:

1. Writing up ORB restructuring notes.

- Potential Optimizations:

1. There is a certain amount of overhead introduced by the use of TSS Singletons. TSS singletons are very convenient as the variable does not have to be passed from function to function. Even though sort of access is generally acceptable, the overhead of this approach maybe too high when used in code which is executed frequently (e.g., during an upcall). This critical code may have to be restructured not to use TSS Singletons because of the high overhead associated with it.

Back to TOC

### Completed Work:

- The ORB was running into some concurrency problems if client thread(s) ran before the server thread(s) got to run the event loop. This problem with the internal Leader/Followers model has been fixed.

- The ORB now supports nested calls to the event loop, i.e., the event loop can be called from the servant code by calling ORB::run() or ORB::perform_work().

- `TAO_ORB_Core_instance()` returns the orb core of the default orb (the first orb created by the user). This may not be the orb that the user is interested in. The better approach is `myorb->orb_core()`.

- Added an optional argument to resolve_initial_references() that allows the user to specify a timeout (an upper bound on the time-to-wait for a response from the ORB's multicast "search" for a running server). If no timeout value is specified by the user, `TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT` is used.

- `ORB::perform_work` and `ORB::work_pending` are now implemented. Some remaining kinks in these methods have recently been fixed.

- Provides dynamically linked wholesale assignment of ORB strategies for communication, concurrency, demultiplexing, scheduling, and dispatching using the ACE Service Configurator framework.

- Supports several concurrency models out of the box: Reactive, Thread-per-Connection, and ORB-per-thread. The ORB-per-thread design is optimized for real-time I/O subsystems. (See: Configuration Guide.)

- Supports `resolve_initial_references("<CORBA Service>")` using ACE support for multicast. (TAO proprietary.)

- Support both native C++ exceptions and `CORBA::Environment` based exceptions handling.

- Support for TAO proprietary `-ORBgioplite` command-line option. When this option is enabled the ORB removes a few fields of the GIOP messages that are normally not used, such as the version numbers, the magic 'GIOP' string, the service context, the Principal object, etc. This option give us a slight performance improvement but it is important for extremely low-latency systems (such as avionics), that fortunately have tightly controlled environments so this kind of optimization is safe to use.

- The buffers for outgoing CDR streams are allocated from TSS memory pools, reducing locking on the critical path.

- Several optimizations on the critical path have been implemented, carefully removing excesive locking, memory allocations and data copying. In some cases special demarshaling and marshaling functions where written for the request headers.

- Adding a new option into TAO_Resource_Factory to control the internal lock used by ORB's reacotr. With "`-ORBreactorlock null`" added into `svc.conf`, you can eliminate the token inside the Select_Reactor inside the ORB even on multi-threaded platforms. This eliminate some overheads caused by synchronizing access to the Select_Reactor. Usually, if you have TSS ORB and are using reactive concurrency startegy, the ORB are not accessed by multiple threads, then, you can safely turn the lock off.

- Strategized the connection management scheme so that we don't always have to pay the price of a look up in the connection cache. Basically, we "hold" a service handler for a string of requests.

- There is no need to call ORB::open if the port is 0. It will automatically be called when the first stub is created.

- The ORB now handles nested upcalls correctly. See this for details on the design of the solution.

- Added optimization for collocated objects. This optimization enables TAO to bypass communication layers and talks to collocated objects directly.

- Making the collocation table configurable. We can either use a global collocation table to share objects among ORBs, or use the per-ORB collocation table.

- Implement the inheritance mechanism in Default_Server_Connection_Handler to access the parent's POA. This is necessary when we are using thread-per-connection concurrency model.

- It is often desireable for a server to start up and not have to specify the TCP port number on which the ORB will listen, i.e., let the OS decide. While this works properly (by providing an argument such as ``-ORBEndpoint iiop://localhost:0`'), the actual port number used by the server won't be available after the server starts listening. TAO now tries to bind the address when a port set to zero is issued so it can get the actual address to publish the IOR for clients' use.

- Broke the tight coupling between `CORBA_Object` and `IIOP_Object` so that multiple `CORBA_Object`s can share a single `IIOP_Object`. This has a big win in `_narrow` operations.

- The ORBs manipulation of object keys and object ids is now consistent. Canonically, everything is managed as an opaque sequence of octets. Conversion to/from strings is permitted, with non-printables turning into a trigraph \hl where h is the high nibble digit in hex, and l is the low nibble in hex.

- `CORBA::ORB::run()` should be able to be called multiply in the same execution path now.

- Fixed the LOCATION_FORWARD capabilities to work as described in the CORBA 2.1 and the POA specification.

- Support for -ORBSndSock and -ORBRcvSock ORB options. See options documentation for details.

- Support for connections pre-establishment using the -ORBPreconnect option. This allows connections to be established before any CORBA requests are made. See options documentation for details.

- Placed an optimization in IIOP::Profile that should speed up invocations on the client side rather substantially. This was done by caching an instance of `ACE_INET_Addr` in the private portion of `Profile` because the cost of constructing one for every invocation (in `TAO_GIOP_Invocation::start`) was simply enormous--the construction was something like 100 cycles on Solaris. This is all because deep down this ends up calling `gethostbyname()`, which can be very costly. Of course, this is platform-dependent, so the improvements may not be as great on a different platform.

- Eliminated need for `CORBA::Object` to keep a pointer to its orb sitting around anywhere.

- Tested `CORBA_ORB::shutdown()` as a manner in which a thread of control can request that `CORBA_ORB::run()` should return and no longer service requests. It only honors a wait_for_completion argument of FALSE right now because we haven't fully explored the issues which surround doing all the completion.

- Implemented `CORBA_ORB::shutdown()` as a manner in which a thread of control can request that `CORBA_ORB::run()` should return and no longer service requests.

- Support for the -ORBInitRef option. This allows run-time specification of an ObjectId<->IOR mapping. It is used by resolve_initial_references() and overrides the ORB install-time defaults.

- minimal support for CORBA Contexts. This is an inherently un-typesafe feature, and many believe it will disappear from CORBA eventually, but in order to make _create_request() compliant, we have added a CORBA_Context class. The only permissible value for a Context pointer passed as an argument to _create_request is 0. If a non-zero pointer is passed, a NO_IMPLEMENT exception is raised.

- Support configuring TAO's component as both static and dynamic services. Improve robustness of setting default svc.conf entries. See Configuration Document for details.

- TAO understands Interoperable Naming Service's `corbaloc:` and `corbaname:` IOR format.

- Added Vendor ID and TAO-specific information to the `CORBA_SystemException` minor status component. The TAO-specific information currently consists of location (in the TAO source code) and errno indications. See `tao/corbafwd.h` for values. `CORBA_SystemException::print_exception_tao_ ()` should be used to print system exceptions. If a known (expected) errno had been received, then it is printed. Otherwise, the low 7 bits of the errno are printed (in decimal). They can be a bit tricky to interpret, for example, because it might have been generated on the server. We only maintain the low 7 bits because of size restrictions on the minor status component.

- The `CORBA::ORB_init()` function returns the same ORB if it is called twice with the same ORBid parameter or if the "-ORBid value" option is present in the argv-list. Please consult the CORBA specification for more details.

- We implemented `GIOP 1.1`, including the support for tagged components in IIOP profiles.

- Added CORBA compliant collocated stubs implementation. The new implementation now query POA for permission to proceed thus fixed many potentially subtle problems. The original collocation implementation is still supported using by specifying the -ORBCollocationStrategy direct command option (because the original scheme has slightly less method invocation overhead.)

- Implemented CORBA::ORB::destroy() method. See the CORBA 2.3a specification for details about this method.

- Implemented shared memory tranpost `SHMIOP`. The performance of shared memory transport is still not optimal but our next step is to improve its performance.

- The Typecode creation functions that were in the ORB have been moved (in accordance with the new Interface Repository spec in CORBA Components volume III) to a separate interface, CORBA::TypeCodeFactory. This has been implemented as a DLL in the directory TAO/orbsvcs/IFR_Service (the Typecode factory is used by the Interface Repository, but it can also be used on its own). To make it available, TAO must be compiled either with the compiler option interface_repo=1 or with #define TAO_HAS_INTERFACE_REPOSITORY 1 uncommented in TAO/tao/orbconf.h. Then build the TypeCodeFactory files in the directory mentioned above. In the application, a call to resolve_initial_references ("TypeCodeFactory") will fetch the object reference, which should then be narrowed from CORBA::Object_ptr.

Back to TOC