1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
|
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<!-- $Id$ -->
<html>
<head>
<title>ORB Core Status</title>
</head>
<BODY TEXT="#000000" BGCOLOR="#FFFFFF">
<H3><A NAME="orb"></A>ORB & ORB Core</H3> Point of
contact: <A HREF="mailto:nanbor@cs.wustl.edu">Nanbor Wang</A>
<p>Last Update: $Date$ </P>
<P>
<b>Current status:</b>
<UL>
<LI>Provides dynamically linked wholesale assignment of ORB
strategies for communication, concurrency, demultiplexing,
scheduling, and dispatching using the ACE Service Configurator
framework.</LI>
<LI>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>.)</LI>
<LI>Supports <TT>resolve_initial_references("NameService")</TT>
using ACE support for multicast.</LI>
</UL><p>
<b>Known issues:</b>
<UL>
<li>Some CORBA objects need to have access to the ORB. We tend to
use TAO_ORB_Core_instance ()->orb () 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.
At the moment, using TAO_ORB_Core_instance ()->orb () is the
only sane way to get arond the problem. Though there may be a
better way.<p>
<li>The acceptor on the server side doesn't get opened until calling
CORBA_ORB::run (). And that's when we check whether the port
the server wants to listen on is available or not. (Unless we
specify ORBport to be 0, which implicitly ask the ORB to open
the connection in ORB_init so we know how to export object
IORs.) The problem of this approach is that the port the server
is listen on may not be available. Since we export object IORs
based on the port specified (or the default port,) without
checking the availability of the port, we may announce a bad IOR
end-point which the server will never be able to listen on.
A possible solution might be opening the server acceptor
whenever it is trying to export an IOR.<p>
<li>The ORB doesn't handle the nested upcalls correctly. This seems
to be stemmed from the incorrect suspension/resumption of file
descriptor in connection management. It appears to work fine
when two client and server calling each other from invoking an
object method. This, however, is broken when a third ORB
makes use of the object exported by the original client when the
nested upcalls are in progress.<p>
<LI>The current demarshalling scheme may not work in cases of
complex types such as sequences of unions or anys or object
references. The engine has difficulty determining the dynamic
type of the objects.<p>
<LI>Object references for objects dynamically created within
a server may not have proper host.</em> (See also <a
href="#hostfix">recent fix</a>.)
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.<br>
However, if there are multiple interfaces on a machine
<i>and</i> 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#-ORBhost"><b>-ORBhost</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>
</Ul>
<b>Recently Completed Work:</b>
<UL>
<li>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.
<li>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.
<li>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 <code>-ORBport 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 <code>-ORBport 0</code> is issued so it can get the
actual address to publish the IOR for clients' use.
<li>Added optimization for collocated objects. This
optimization enables TAO to bypass communication layers and
talks to collocated objects directly.</li>
<li>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.</li>
<li>Eliminated substantial memory leaks in servers.</li>
<li>Added documentation for <a
href="../Options.html#-ORBpoa"><b>-ORBpoa</b></a>, which
allows individual tweaking of the POA's locality (global
vs. thread-specific) independent of the locality of other
ORB resources. Also, <a
href="../Options.html#-ORBpoalock"><b>-ORBpoalock</b></a>
and <a
href="../Options.html#-ORBpoamgrlock"><b>-ORBpoamgrlock</b></a>
control locking in the POA and POA manager, respectively,
according to application needs.</li>
<li>Began the process of changing the internals of TAO to use
the "underbar" namespace mapping. This should be completed
soon.</li>
<li>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.</li>
<li><code>CORBA_ORB::run()</code> should be able to be called
multiply in the same execution path now.</li>
<li>Fixed the <b>LOCATION_FORWARD</b> capabilities to work as
described in the CORBA 2.1 and the POA specification.</li>
<li>Fixed problem in the IDL Cubit example which caused the
server to dump core when dealing with <code>_out</code> sequence
types <em>ONLY</em> when compiled with G++. It seems that G++
decided to interpret the expression <code>output == 0</code>
(where <code>output</code> is of type <code>vector_out</code>)
differently from Sun's C++ compiler.</li>
<li>Fixed a slight problem in <a href="#hostfix">other recent
work</a> where a servant listening on <code>INADDR_ANY</code>
reported an IOR with address <tt>0.0.0.0</tt>. It now reports
the default hostname instead.</li>
<LI>Working version of TAO on VxWorks with VME transport.</li>
<li>TAO now reacts gracefully in the face of a non-existent
<code>svc.conf</code> file or simply missing entries in the
file. It logs a warning message and uses default values
versions of items which it would normally obtain from the
Service Repository.</li>
<li><a name="hostfix"></a>Fixed problem where object references
for objects dynamically created within a server do not have
proper host, at least if the desired host was specified using <a
href="../Options.html#-ORBhost"><b>-ORBhost</b></a> on the
command line.</li>
<li>Added support for <a
href="../Options.html#-ORBsndsock"><b>-ORBsndsock</b></a> and <a
href="../Options.html#-ORBrcvsock"><b>-ORBrcvsock</b></a> ORB
options. See <a href="../Options.html">options
documentation</a> for details.</li>
<li>Added support for pre-established connections using the <a
href="../Options.html#-ORBpreconnect"><b>-ORBpreconnect</b></a>
option. This allows connections to be esablished before any
CORBA requests are made. See <a href="../Options.html">options
documentation</a> for details.</li>
<li>Eliminated deprecated <b>-OAxxx</b> options parsed by the
Object Adapter <code>init</code> method but no longer used by
part of the ORB.</li>
<li>Made argument parsing within the ORB and POA consume the
arguments it parses.</li>
<li>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.</li>
<li>Got rid of need to have compile in TSS ORB Core
(<code>-DTAO_HAS_TSS_ORBCORE</code>). This is accomplished by
having a Resource Factory (<code>TAO_Resource_Factory</code>)
singleton which the ORB Core consults in order to get pointers
to resources. The Resource Factory can be configured to
return pointers from thread-specific storage, or
process-global storage. By doing this, the ORB Core is
shielded from ever having to know whether or not its resources
are global or not.</li>
<li>Made all command-line like options look like the
standard-professed options, i.e., <b>-ORBxxx</b> or
<b>-OAxxxx</b>.</li>
<li>Moved ORB option parsing into
<code>TAO_ORB_Core::init()</code> rather than in
<code>ORB_init()</code>.</li>
<li>Define <code>_FAR</code> for all cases as an interim fix
for LynxOS.</li>
<li>Fixed TAO so that the default port of 5001 is defined in
<code>orb_core.h</code> config header somewhere rather than in
<code>orbobj.cpp</code>, and use <b>MAXHOSTNAMELEN</b> ACE
constant for the hostname buffer.</li>
<li>Eliminated need for <code>CORBA::Object</code> to keep a
pointer to its orb sitting around anywhere.</li>
<LI>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.</li>
<li>Created a brief section in <a
href="../../TAO-INSTALL.html"><code>$TAO_ROOT/TAO-INSTALL.html</code></a>
that <em>briefly</em> documents installation on Unix
platforms. There is also a brief section which documents
issues that apply across ALL platforms, such as the fact that
TAO and its application will likely not work well if your ACE
is linked through Orbix, VisiBroker, or another ORB. <a
href="../../ChangeLog">ChangeLog</a> discovery attribution for
this should go to <em>Steve Wohlever
<wohlever@mitre.org></em>.</li>
<LI>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.</li>
<LI>Validated movement of Strategy Connector into
ORB Core.</LI>
<li>Tested and commited <code>Connector::connect_n</code>
changes to ACE</code>.</li>
<li>ACE & TAO compiling cleanly using Sun's CC on Solaris and
G++ on Linux. Also, the ACE tests run properly.</li>
<li>Use <code>truss</code> to verify for <a
href="mailto:PAUL.G.WEHLAGE@cdev.com">Paul Wehlage</a> that
TAO really uses <code>select</code> vs. <code>recv</code> for
<b>-R</b> vs. <b>-T</b>.</li>
<li>Renamed <code>boa.*</code> to <code>poa.*</code>.</li>
<LI>Renamed following files: Orb_Core.* ->orb_core.*
& orbobj.* -> corba_orb.*.</LI>
<LI>The lock used in <code>giop.cpp:626</code> originally
appeared in the IIOP-1.4 code base. Its purpose was to
protect access to the <code>fwd_profile</code> data member.
The original features are available, but they are currently
not used because none of our concurrency models present a
thread-unsafe condition. The <a
href="../../ChangeLog">ChangeLog</a> presents more details
on the subject.</li>
<li>Fixed problems seen by <a
href="mailto:brian.r.mendel@boeing.com">Brian Mendel</a> of
Boeing where the Cubit server application was crashing in
<code>TAO_OA_Connection_Handler::handle_message</code> when it
was trying to call <code>CORBA::POA::handle_request</code>
through a NULL <code>root_poa</code> pointer. The NULL
pointer resulted from the inadvertent use of the
Thread-per-Connection concurrency model, which is currently
incompatible with the ORB-per-thread model. It was not caught
because the change is normally done in configuration files
parsed by the Service Configurator, and VxWorks requires
special code in that area which was not tested until Boeing
got hold of the code.</li>
<li>Clean up build under g++. All 'function used before
declared inline' warnings have been eliminated. Also, all
other warnings (except for one that is nearly unavoidable)
have been eliminated.
</li>
<LI>Removed BOA and ROA names from the ORB.</LI>
<LI>Changed <code>CORBA_ORB::open()</code> to return an error
status (first cut at this already there--needs to be checked
out).</LI>
<LI>Added README file to multiCubit test.</li>
</UL><p>
<b>Ongoing Work:</b>
<UL>
<LI>Verify ACE & TAO on Linux using g++, Solaris using CC, and
Solaris using g++.</LI>
<LI>Use Purify to eliminate straggling problems.</LI>
<LI>Clean up the internals and analyze for performance
bottlenecks using Quantify.</LI>
<li>Resolve <code>// @@</code> comment blocks. These are
questions or comments placed in the code by a reviewer
(typically Doug).</li>
<li>Make more and better documentation on the internals of
TAO.</li>
</UL><p>
<b>Current Work:</b>
<UL>
<LI>
<p>Verify that, in the ORB-per-thread concurrency model,
it's possible to have a factory in each thread that creates
a client and returns an object reference to that client
within that thread. This is different from the model that
Sumedh originally had where the factory was trying to turn
out a client in a separate thread/ORB combination.
<p>There is no application which attempts this at the moment,
so both a client and a server will need to be manufactured.
Using existing Cubit-like examples (that poor app is so
weary) should reduce development time to a couple of
hours.
<p>The real strategy/solution is to make
<code>CORBA::Object</code> not keep a pointer to its orb
sitting around anywhere. It should only get it when it needs
it. This should not be difficult to change.
</LI>
</UL><p>
<b>Critical Work:</b>
<UL>
<li>Identify/fix the problems in multithreaded client with TSS
resources. This could be done using the leader-follower model
(thread-pool.)
<LI>Support new concurrency models, e.g., Thread-per-Request,
thread pool, etc..</LI>
</UL>
<b>Future work:</b>
<UL>
<li>Performance optimizations, such as:
<ol>
<li>Strategize 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 want to be able to "hold" a
service handler for a string of requests. And, of course,
do this in a portable manner.</LI>
<li>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.</li>
</ol>
</li>
<li>Robustness improvements:
<ol>
<li>Improve connection cache so that it won't crash when there
are no more slots or sockets.</li>
<li>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.</li>
</ol>
</li>
<li>New features:
<ol>
<li>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.</li>
<li>Improve the <code>Service Configurator</code> service
entry faking on VxWorks.</li>
<li>Integrate with realtime upcalls (RTUs).</li>
</ol>
</li>
<li>Internal restructuring:
<ol>
<li>Remove <code>_FAR</code> from all code.</li>
<li>Rework underlayment to eliminate <code>IUnknown</code> class.</li>
<li>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.</li>
<li>Rethink the entire memory allocation model used by the
ORB. The current one from SSIIOP may no longer be suitable
for our purposes.</li>
</ol>
</li>
<li>Documentation:
<ol>
<li>Update ORB Patterns paper to reflect the latest TAO has to
offer. Specifically
<ul>
<li>sections on the Abstract Factory and Concurrency
strategies need to be updated, and the entire paper needs to
be reviewed for accuracy w.r.t the current TAO.</li>
<li>Metrics must be re-computed.</li>
<li>Tighten existing discussions.</li>
<li>Add information on new patterns (such as TSS) which
have been used since initial work.</li>
</ul>
<li>Make the section in <a
href="../../TAO-Install.html"><code>$TAO_ROOT/TAO-Install.html</code></a>
that documents installation on Unix platforms more complete.</li>
</ol> </li>
<li>Miscellany:
<ol>
<LI>Assist in porting higher level services (e.g., <A
HREF="#eventchannel">Event Channel</A>) to TAO.</LI>
<li>Compile and verify ACE and TAO on Linux using the Kuck and
Associates, Inc. (KAI) compiler tools.</li>
<LI>CORBA::TypeCode is causing a memory leak. Since objects
of this type are rather static in nature, this is
currently not a big deal. However, it should be fixed
soon. </LI>
<LI>CORBA_Exception::Release is not working correctly as the
memory is never really freed. </LI>
</ol>
</li>
<li>Potential Optimizations:
<ol>
<LI>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. </LI>
</ol>
</li>
</UL>
</body>
</html>
|
