ChangeLogTag:Sun Aug 04 09:56:29 2002 Balachandran Natarajan <bala@cs.wustl.edu>

2 files changed, 121 insertions, 366 deletions

diff --git a/TAO/ChangeLog b/TAO/ChangeLog
index 25fa0516ef6..6c9aa3ce38f 100644
--- a/TAO/ChangeLog
+++ b/TAO/ChangeLog
@@ -1,3 +1,10 @@
+Sun Aug 04 09:56:29 2002  Balachandran Natarajan  <bala@cs.wustl.edu>
+
+	* docs/releasenotes/orbcore.html: Updated the release notes. Looks
+	  like it was woefully out-of-date! Included some of the latest
+	  concerns and plans in it. Need to make a pass again before the
+	  beta goes out of the door.
+
 Sun Aug  4 15:31:12 UTC 2002  Johnny Willemsen  <jwillemsen@remedy.nl>
 
         * tao/Invocation.h:
diff --git a/TAO/docs/releasenotes/orbcore.html b/TAO/docs/releasenotes/orbcore.html
index 3f7ee0f9de1..394eaa62ba8 100644
--- a/TAO/docs/releasenotes/orbcore.html
+++ b/TAO/docs/releasenotes/orbcore.html
@@ -21,7 +21,7 @@
 <center>
 <h1> <a name="orb"></a>ORB &amp; ORB Core</h1>
 
-Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
+Point of contact: <a href="mailto: bala@cs.wustl.edu">Balchandran Natarajan</a>
 
 <p>Last Update: $Date$</p>
 </center>
@@ -31,7 +31,7 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
 
 <ul>
 
-  <li><p>We are fully compliant with OMG 2.2 / 2.3 spec.</p>
+  <li><p>We are compliant with OMG's CORBA 2.6 specification. </p>
   </li>
 
 </ul>
@@ -44,35 +44,36 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
 <a name="issues"><h3>Known issues:</h3></a>
 
 <ul>
-  <li><p>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.</p>
-  </li>
-
-  <li><p>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 <em>and</em> 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 <A
-      HREF="../Options.html#-ORBEndpoint"><b>-ORBEndpoint</b> option</a> 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.</p>
-  </li>
+  <li><p> TAO's support for wstring as per GIOP 1.2 rules are not
+      perfect. There have been reported interoperability
+      problems. <p></li>
+
+  <li><p> There is a known race condition with the TP_Reactor. It
+      kicks up when a client running multiple threads, sees a remote
+      server crash or do an abnormal exit . The details of this bug
+      are documented <A
+      HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1020"> 
+      here </A> <p></li>
+
+  <li><p> The multi-profile parsing code in TAO hasnt been tested well
+      and we have been able to identify some issues with it. The
+      details are documented in bugzilla under id's  <A
+      HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1237">1237</A>, <A
+      HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1238">
+      1238</A> and <A
+      HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1239">1239</A> <p></li>
+
+  <li><p> Applications using the distributed callback paradigm could
+      see crashes if they use multiple nested upcalls. The nested
+      upcalls sets of a stack growth and crashes when it runs out of
+      stack space. This happens when an upcall as a part of the
+      request leads to another request. The client thread waiting for
+      the reply in the reactor could in turn process yet another
+      request to build up the stack. The unbounded growth on the stack
+      leads to crash failures. <p>
+  </li>
+
+      
 </ul>
 <!-- --------------------- -->
 <a href="#toc">Back to TOC</a>
@@ -82,30 +83,23 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
 <a name="ongoing"><h3>Ongoing Work:</h3></a>
 
 <ul>
-  <li><p>Trying to figure out a better <em>resource</em> management
-          scheme.  <em>Resouces</em> here include ORB, POA, connections,
-          profiles.... that provide services for CORBA invocations.
-        </p>
-        <P>[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.
-        </P>
+  <li><p> Work is on to write a new <A
+      HREF="http://deuce.doc.wustl.edu/bugzilla/show_bug.cgi?id=1031"> 
+      reactor </A> framework for TAO which overcomes some of the
+      problems associated with the new reactor<p></li>
   </li>
-
   <li><p>Support new concurrency models, e.g., Thread-per-Request,
       etc..</p>
   </li>
+  <li><p>Improvement to connection cache on the acceptor side so that
+      it will purge old connections when there are no more slots or
+      sockets are available. The connection cache does good job of
+      purging things on the connector side</p> 
+  </li>
 
-  <li><p>Robustness improvements to connection cache so that it will
-      purge old connections when there are no more slots or sockets
-      are available.</p>
-
-      <P>[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. </P>
-
+  <li><p> Prevent unbounded stack growth that leads to a failure in
+      situations explained in <a href="#issues"> known issues
+      </a>.</p>   
   </li>
 
 </ul>
@@ -117,47 +111,35 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
 <a name="future"><h3>Future work:</h3></a>
 
 <ul>
-  <li>Performance optimizations, such as:</li>
-      <ol>
-        <li><p>Replace all uses of <code>new</code> and <code>delete</code>
-            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.</p>
-        </li>
-      </ol>
-
-  <li>Internal restructuring:</li>
+  <li>Performance bottlenecks:</li>
       <ol>
-        <li><p>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.</p>
+        <li><p> Need to identify performance bottlenecks. Looks like
+        TAO has slowed down a bit over the past two betas. Need to
+        identify the bottlenecks before improving the performance.</p>
         </li>
-      </ol>
-
-  <li>Documentation:</li>
-    <ol>
-        <li><p>Writing up ORB restructuring notes.</p>
+        
+        <li><p> Its a known fact that thread-per-connection is faster
+        than the reactive model, even for single threaded cases. Need
+        to identify portions of the reactor that slows down things and
+        fix them or create a fast path in the ORB just using plain
+        vanilla select for the server.</p>
         </li>
+        
+        <li><p> In the output data path, the CDR creates the message
+        block and all other associted things on TSS. If we could
+        change the CDR to first create them on the stack and then move
+        the data to TSS we could achieve better performance for small
+        messages.
       </ol>
 
-  <li>Potential Optimizations:</li>
 
+  <li>Features:</li>
       <ol>
-        <li><p>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.</p>
-        </li>
+        <li><p>Implement DP-CORBA specification</p></li>
+        
+        <li><p>Implement TII specification.</p></li>
       </ol>
+
 </ul>
 <!-- --------------------- -->
 <a href="#toc">Back to TOC</a>
@@ -170,292 +152,58 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
 <!-- Please make sure you append new items at the end of the list -->
 <!-- ************************************************************ -->
 <ul>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>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().</p>
-  </li>
-
-  <li><p><code>TAO_ORB_Core_instance()</code> 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 <code>myorb->orb_core()</code>.</p>
-  </li>
-
-  <li><p>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,
-      <code>TAO_DEFAULT_SERVICE_RESOLUTION_TIMEOUT</code> is
-      used.</p>
-  </li>
-
-  <li><p><code>ORB::perform_work</code> and
-      <code>ORB::work_pending</code> are now implemented.  Some
-      remaining kinks in these methods have recently been fixed.</p>
-  </li>
-
-  <li><p>Provides dynamically linked wholesale assignment of ORB
-      strategies for communication, concurrency, demultiplexing,
-      scheduling, and dispatching using the ACE Service Configurator
-      framework.</p>
-  </li>
-
-  <li><p>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: <A
-      HREF="../configurations.html">Configuration Guide</a>.)</p>
-  </li>
-
-  <li><p>Supports <code>resolve_initial_references("&lt;CORBA
-      Service>")</code> using ACE support for multicast. <em>(TAO
-      proprietary.)</em></p>
-  </li>
-
-  <li><p>Support both native C++ exceptions and
-      <code>CORBA::Environment</code> based exceptions handling.</p>
-
-  <li><p>Support for TAO proprietary <code>-ORBgioplite</code>
-      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.</p>
-  </li>
-
-  <li><p>The buffers for outgoing CDR streams are allocated from TSS
-      memory pools, reducing locking on the critical path.</p>
-  </li>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>Adding a new option into TAO_Resource_Factory to control the
-      internal lock used by ORB's reacotr. With "<code>-ORBreactorlock
-      null</code>" added into <code>svc.conf</code>, 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.</p>
-  </li>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>There is no need to call ORB::open if the port is 0. It will
-      automatically be called when the first stub is created.</p>
-  </li>
-
-  <li><p>The ORB now handles nested upcalls correctly. See <a
-      href="../leader_follower.html">this </a>for details on the
-      design of the solution.</p>
-  </li>
-
-  <li><p>Added optimization for collocated objects. This optimization
-      enables TAO to bypass communication layers and talks to
-      collocated objects directly.</p>
-  </li>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>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
-      `<code>-ORBEndpoint iiop://localhost:0</code>'), 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.</p>
-  </li>
-
-  <li><p>Broke the tight coupling between <code>CORBA_Object</code>
-      and <code>IIOP_Object</code> so that multiple
-      <code>CORBA_Object</code>s can share a single
-      <code>IIOP_Object</code>. This has a big win in
-      <code>_narrow</code> operations.</p>
-  </li>
-
-  <li><p>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 <b>\hl</b> where
-      <b>h</b> is the high nibble digit in hex, and <b>l</b> is the
-      low nibble in hex.</p>
-  </li>
-
-  <li><p><code>CORBA::ORB::run()</code> should be able to be called
-      multiply in the same execution path now.</p>
-  </li>
-
-  <li><p>Fixed the <b>LOCATION_FORWARD</b> capabilities to work as
-      described in the CORBA 2.1 and the POA specification.</p>
-  </li>
-
-  <li><p>Support for <b><a
-      href="../Options.html#-ORBSndSock">-ORBSndSock</a></b> and <b><a
-      href="../Options.html#-ORBRcvSock">-ORBRcvSock</a></b> ORB
-      options. See <a href="../Options.html">options documentation</a>
-      for details.</p>
-  </li>
-
-  <li><p>Support for connections pre-establishment using the <b><a
-      href="../Options.html#-ORBPreconnect">-ORBPreconnect</a></b>
-      option. This allows connections to be established before any
-      CORBA requests are made. See <a href="../Options.html">options
-      documentation</a> for details.</p>
-  </li>
-
-  <li><p>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 <code>ACE_INET_Addr</code> in the
-      private portion of <code>Profile</code> because the cost of
-      constructing one for every invocation (in
-      <code>TAO_GIOP_Invocation::start</code>) was simply
-      enormous--the construction was something like 100 cycles on
-      Solaris. This is all because deep down this ends up calling
-      <code>gethostbyname()</code>, which can be very costly. Of
-      course, this is platform-dependent, so the improvements may not
-      be as great on a different platform.</p>
-  </li>
-
-  <li><p>Eliminated need for <code>CORBA::Object</code> to keep a
-      pointer to its orb sitting around anywhere.</p>
-  </li>
-
-  <li><p>Tested <code>CORBA_ORB::shutdown()</code> as a manner in
-      which a thread of control can request that
-      <code>CORBA_ORB::run()</code> should return and no longer
-      service requests. It only honors a <em>wait_for_completion</em>
-      argument of <b>FALSE</b> right now because we haven't fully
-      explored the issues which surround doing all the completion.</p>
-  </li>
-
-  <li><p>Implemented <code>CORBA_ORB::shutdown()</code> as a manner in
-      which a thread of control can request that
-      <code>CORBA_ORB::run()</code> should return and no longer
-      service requests.</p>
-  </li>
-
-  <li><p>Support for the -ORBInitRef option. This allows run-time
-      specification of an ObjectId&lt;-&gt;IOR mapping. It is used by
-      resolve_initial_references() and overrides the ORB install-time
-      defaults.</p>
-  </li>
-
-  <li><p>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.</p>
-  </li>
-
-  <li><p>Support configuring TAO's component as both static and
-      dynamic services.   Improve robustness of setting default
-      svc.conf entries.  See <a
-      href="../configurations.html#programming">Configuration
-      Document</a> for details.</p>
-  </li>
-
-  <li><p>TAO understands <a
-      href="index.html#nservices">Interoperable Naming Service</a>'s
-      <code>corbaloc:</code> and <code>corbaname:</code>
-      IOR format.</p>
-  </li>
-
-  <li><p>Added Vendor ID and TAO-specific information to
-     the <code>CORBA_SystemException</code> minor status component.
-     The TAO-specific information currently consists of location
-     (in the TAO source code) and errno indications.  See
-     <a href="../tao/corbafwd.h"><code>tao/corbafwd.h</code></a>
-     for values.  <code>CORBA_SystemException::print_exception_tao_ ()</code>
-     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.</p>
-  </li>
-
-  <li><p>The <CODE>CORBA::ORB_init()</CODE> 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.
+    <li><p> Implemented a connection timeout policy in the ORB. This
+        is useful for applications to set a timeout value associated
+        with connection establishment. The name of the policy is
+        <code>TAO::CONNECTION_TIMEOUT_POLICY_TYPE</code> and is
+        proprietary to TAO. It comes as a prt of the TAO_Messaging
+        library. Please see
+        <code>$TAO_ROOT/tests/Connection_Timeout</code> for an example
+        of how to use this feature.<p>
+    </li>
+        
+    <li><p> Implemented non-blocking connects with three different
+        strategies for connection establishment. The details of the
+        strategies and the related documentation can be found <A
+        href="../Options.html"> here </a>.</p>
+    </li>
+
+    <li><p> Deprecated the option -ORBConnectionCachingStrategy. The
+    option -ORBConnectionPurgingStrategy fills in the role of the
+    deprecated strategy.</p>
+    </li>
+    
+    <li><p> Deprecated the option -ORBResources.</p></li>
+
+    <li><p> The connectors have been moved to the lanes.</p> </li>
+    
+    <li><p> Fixed stack recursion problems that occurs, when a thread
+        flushing a reply by entering the reactor starts processing
+        incoming requests.</p>
+    </li>
+
+    <li><p> Fixed connection handling and connection closing problems,
+        when a write call to a remote host fails. </p>
+    </li>
+
+    <li> <p> Moved the allocators used for allocating memory for the
+        incoming data path to the lanes. Only allocators on the
+        incoming data path are moved into the lanes. Allocators on the
+        outgoing data path are still on a per-orb basis. Since the
+        outgoing data path uses memory from the TSS, moving them to
+        the lanes is not necessary.
         </p>
-  </li>
-
-  <li><p>We implemented <CODE>GIOP 1.1</CODE>, including the support
-          for tagged components in IIOP profiles.
+    </li>
+    <li><p> Added an option, -ORBSingleReadOptimization that allows
+        users to turn on or turn off the single read
+        optimization. This is useful for RTCORBA server threads to
+        avoid priority inversions. Buffering messages and sending
+        notifications to the reactor, that does not know or honour
+        priority could lead to priority inversions. 
         </p>
-  </li>
-
-  <li><p>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.)</p>
-  </li>
-
-  <li><p>
-      Implemented CORBA::ORB::destroy() method.  See the CORBA 2.3a
-      specification for details about this method.
-      </p>
-  </li>
-
-  <li><p>
-      Implemented shared memory tranpost <CODE>SHMIOP</CODE>.  The
-      performance of shared memory transport is still not optimal but
-      our next step is to improve its performance.
-      </p>
-  </li>
-
-  <li><p>
-      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.
+    </li>
 
+    
 </ul>
 <!-- --------------------- -->
 <a href="#toc">Back to TOC</a>