summaryrefslogtreecommitdiff
path: root/TAO/docs/releasenotes/orbcore.html
diff options
context:
space:
mode:
Diffstat (limited to 'TAO/docs/releasenotes/orbcore.html')
-rw-r--r--TAO/docs/releasenotes/orbcore.html112
1 files changed, 68 insertions, 44 deletions
diff --git a/TAO/docs/releasenotes/orbcore.html b/TAO/docs/releasenotes/orbcore.html
index 6903647c1f3..fc3c839542b 100644
--- a/TAO/docs/releasenotes/orbcore.html
+++ b/TAO/docs/releasenotes/orbcore.html
@@ -12,6 +12,7 @@
<li><a href="#current">Current Status</a>
<li><a href="#issues">Known Issues</a>
<li><a href="#ongoing">Ongoing work</a>
+ <li><a href="#rework">Rework Notes</a>
<li><a href="#future">Future Work</a>
<li><a href="#completed">Completed Work</a>
</ul>
@@ -31,15 +32,8 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</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>
+ scheme. <em>Resouces</em> here include ORB, POA, connections,
+ profiles.... that provide services for CORBA invocations.</p>
</li>
</ul>
@@ -51,12 +45,27 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
<a name="issues"><h3>Known issues:</h3></a>
<ul>
+ <li><p>Since collocated objects run in the client thread's context,
+ calling <code>CORBA::ORB::shutdown()</code> does <em>not</em>
+ actually close down the target ORB but instead on the client
+ side ORB. This issue will be addressed in the new ORB Core
+ architecture.</p>
+
+ <p>Also, since the collocated invocations circumvent POA
+ completely, POA Current won't get set up, LOCATION_FORWARD will
+ not work, race condition may occur when several threads invoke
+ operations on an objects registered with POAs with SINGLE_THREAD
+ policy, operation invocations will still get thru even the POA
+ is in holding state, or invoking operations on a servant that
+ has already been deactivated.</p>
+ </li>
+
<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
+ gets kill by the OS. This is especially a problem on NT becuase
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
@@ -64,6 +73,26 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
down. But this is not portable and only works on NT.</p>
</li>
+ <li><p>Some CORBA objects need to have access to the ORB. We tend to
+ use <code>TAO_ORB_Core_instance()->orb()</code> to fetch the
+ right ORB the object is using. This is most often true when
+ implementing the shutdown method which allow other process to
+ shutdown a remote ORB. Althought this may be the "right" thing
+ to do in TAO, it is not CORBA compliant and hurts the
+ portability of object implementation. A common way of getting
+ around this problem is to cache the ORB pointer in the object
+ when it is created and simply use the cached ORB when needed.
+ However, remember that there could be multiple ORBs in a process
+ and a POA may be shared by several ORBs. That means, we may not
+ handling the object with the same ORB it was
+ created. Collocation optimization further complicated the
+ problem.</p>
+
+ <p> At the moment, using
+ <code>TAO_ORB_Core_instance()->orb()</code> is the only sane way
+ to get arond the problem. Though there may be a better way.</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
@@ -92,6 +121,11 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
<li><p>ORB Core overhaul.</p>
</li>
+ <li><p>Identify/fix the problems in multithreaded client with TSS
+ resources. This could be done using the leader-follower model
+ (thread-pool.)</p>
+ </li>
+
<li><p>Support new concurrency models, e.g., Thread-per-Request,
thread pool, etc..</p>
</li>
@@ -101,6 +135,19 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
<!-- --------------------- -->
<!-- ============================================================ -->
+<a name="rework"><h3>Rework Notes:</h3></a>
+
+Here are some thoughts/points of concern that we have regarding the
+new ORB Core structure.
+
+<ul>
+ <li>
+</ul>
+<!-- --------------------- -->
+<a href="#toc">Back to TOC</a>
+<!-- --------------------- -->
+
+<!-- ============================================================ -->
<a name="future"><h3>Future work:</h3></a>
<ul>
@@ -121,10 +168,21 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
<li><p>Improve connection cache so that it won't crash when
there are no more slots or sockets.
</li>
+
+ <li><p>Add an option to the ORB core, e.g.,
+ <b>-ORBnameservicetimeout</b>, to allow specification of
+ an upper bound on the itime-to-wait for a response from
+ the ORB's multicast "search" for a running name server.<p>
+ </li>
</ol>
<li>New features:</li>
<ol>
+ <li><p>Implement <code>ORB::perform_work</code> and
+ <code>ORB::work_pending</code> so that <code>ORB::run</code>
+ <em>could</em> be implemented in terms of them.</p>
+ </li>
+
<li><p>Implement <code>RT-CORBA</code> spec. once it passes
OMG member vote.</p>
</li>
@@ -179,27 +237,6 @@ 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><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.
- <code>ORB::work_pending</code> may need some additional work
- in the future (since it currently always returns true).</p>
- </li>
-
<li><p>Provides dynamically linked wholesale assignment of ORB
strategies for communication, concurrency, demultiplexing,
scheduling, and dispatching using the ACE Service Configurator
@@ -408,19 +445,6 @@ Point of contact: <a href="mailto: irfan@cs.wustl.edu">Irfan Pyarali</a>
</p>
</li>
- <li><p>We implemented <CODE>GIOP 1.1</CODE>, including the support
- for tagged components in IIOP profiles.
- </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.)
- </li>
-
</ul>
<!-- --------------------- -->
<a href="#toc">Back to TOC</a>