summaryrefslogtreecommitdiff
path: root/TAO/docs/configurations.html
blob: 13776d795fa16aa86e8e8ab84bbccdc22d052377 (plain)
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
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
<!-- $Id$ -->
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Mozilla/4.5 [en] (WinNT; I) [Netscape]">
<title>Configuring TAO's Components</title>
</head>

<body text="#000000" bgcolor="#FFFFFF" link="#000FFF" vlink="#FF0F0F">

<hr>
<h3>
Configuring TAO's Components</h3>

<h3> Overview</h3>

<p> As described in the <a href="Options.html">options</a>
documentation, various components in TAO can be customized by
specifying options for those components.  This document illustrates
how to combine these options in order to affect ORB behavior and
performance, particularly its <a
href="http://www.cs.wustl.edu/~schmidt/CACM-arch.ps.gz">concurrency
model</a>.  </p>

<p> TAO configures itself using the <a
href="http://www.cs.wustl.edu/~schmidt/Svc-Conf.ps.gz">ACE
Service Configurator</a> framework. Thus, options are specified in the
familiar <tt>svc.conf</tt> file (if you want to use a different file
name, use the <tt><a href="Options.html#svcfonf">-ORBSvcConf</a></tt>
option).  You can also setup default configurations for your programs.
Please see the <a href="#programming">Programming Considerations</a>
for more detailed discussion on this.</p>

<hr>
<h3>
Roadmap</h3>

<blockquote>Details for the following configurations are provided.
<ul>
  <li><b><a href="#comp">Configurating key components</a>:</b></li>

      <ul>
        <li><a href="#concurrency">Server Concurrency Strategy.</a></li>

        <li><a href="#orb">Number of ORBs.</a></li>

        <!-- <li><a href="#orb_resources">ORB resources.</a></li> -->

        <li><a href="#poa">POA.</a></li>

        <li><a href="#coltbl">Collocation Table.</a></li>

        <li><a href="#profile">Forwarding Profile</a></li>

        <li><a href="#orbsvcs">orbsvcs Library</a></li>
      </ul>

  <li>
      <b><a href="#examples">Configuration examples</a></b></li>

      <ul>
        <li><a href="#reactive">Single-threaded, reactive model.</a></li>

        <li><a href="#tpc">Single ORB, multiple threads, thread-per-connection
            model.</a></li>

        <li><a href="#multiorb">Multiple threads, multiple ORBs,
            reactive model.</a></li>

        <li><a href="#multiorb-tpc">Multiple threads, multiple ORBs,
            thread-per-connection model.</a></li>

        <li><a href="#tpool">Multiple threads, thread-pool model.</a></li>

        <li><a href="#multiorb-tpool">Multiple threads,
            ORB-per-thread, thread-pool reactive model.</a></li>

        <li>
            Each configuration has the following information:</li>

            <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="70%">
              <tr>
                <th align=left>Typical Use</th>

                <td>A brief description of the scenario and
                    its typical use.</td>
              </tr>

              <tr>
                <th align=left>Number of Threads</th>

                <td>The number of threads used by
                    ORB-related activities.</td>
              </tr>

              <tr>
                <th align=left>Thread Creator</th>

                <td>Identifies the creator of the threads
                    discussed above.</td>
              </tr>

              <tr>
                <th align=left>Thread task</th>

                <td>Describes what task is undertaken for
                    each thread.</td>
              </tr>

              <tr>
                <th align=left>Options</th>

                <td>Specifies the options for each service in order to
                    utilize this configuration.</td>
              </tr>
            </table>
      </ul>

  <li><b><a href="#programming">Programming considerations</a></b>

  <li><b><a href="#homogenous">Configuration for homogenous systems</a></b></li>

      <ul>
        <li><a href="#homogenous_compile">Compile time options</a></li>

        <li><a href="#homogenous_runtime">Runtime time</a></li>
      </ul>
</ul>
</blockquote>

<hr>
<h3>
<a NAME="comp"></a>Configuring Key ORB Components</h3>

<ul>
  <li><a name="orb"><b>Number of ORBs</b> -- </a></li>
      TAO can assign multiple endpoints to an ORB.  Therefore,
      it is not necessary to create multiple ORBs to accept
      requests from multiple endpoints.  However, multiple ORBs can be
      used to support different policies within the same process,
      <EM>e.g.</EM>, handling requests in different thread
      priorities.  Multiple ORBs are most commonly used in the "ORB
      per-priority" pattern to avoid priority inversion in real-time
      system. <p>

  <li><a NAME="concurrency"></a><b>Server concurrency strategy</b> --
      The default server strategy factory provided by down support two
      different concurrency strategy.  It can be specified by adding
      the <tt>-ORBConcurrency</tt> flag in the <code><a
      href="Options.html#orb_concurrency"> Server_Strategy_Factory
      </a></code> entry of the <code>svc.conf</code> file. This
      specifies the concurrency strategy an ORB uses.  This strategy
      is orthogonal the the number of ORBs or threads that are
      configured in a server process.  </li><P>

      <ul>
        <li><tt>reactive</tt>: The ORB handles requests reactively,
            i.e., the ORB runs in one thread and service multiple
            requests/connections simultaneously using the
            <A
            HREF="http://www.cs.wustl.edu/~schmidt/ACE-papers.html#reactor">
            ACE_Reactor</A>, which uses <tt>select</TT> or a similar
            event demultiplexing mechanism supported by the
            platform. </li> <P>

        <li><tt>thread-per-connection</tt>: The ORB handles new
            connections by spawning a new thread whose job is to
            service requests coming from the connection.</li>
      </UL><P>

  <li><a name="orb"><b>Thread Pools</b></a></li> --
      TAO supports several types of thread pools. <P>

      <ul>
        <li><tt>reactive</tt>: In this approach, each thread
        in the thread pool has an ORB that accepts and processes
            requests reactively. <P>

        <li><P><tt>leader/follower</tt>: In this model, the user must
	  create several threads, all of which invoke
	  <CODE>ORB::run</CODE>, the ORB will select one of the threads
	  to wait for incoming requests.
	  This thread is called the leader thread and will process the
	  first request that arrives to the ORB, but before
	  doing so the ORB will selects another thread in the pool to
	  become the leader.
	  In other words the threads in the pool take turns to
	  process the events.
	</p>
	<p>
	  Notice that this configuration requires the
	  <CODE>ACE_TP_Reactor</CODE>, i.e.
	  you must use the <CODE>-ORBReactorType tp</CODE> in the
	  configuration file.
	</p>
	</li>

      </UL><P>

  <!--
  <li><a NAME="orb_resources"></a><b>ORB resources</b> --

      <ul>
        <li><tt>global</tt>: All threads using the ORB access to
            the a set of global per-ORB resources. The same set of
            pre-ORB resources are shared by all threads accessing the
            ORB.  Notice that if you have more than one ORB, each ORB
            owns its own global resources.

        <li><tt>tss</tt>: Each thread accessing an ORB gets its own
            set of thread-specific resources for the ORB.

            <!-- @@ What about resource inheritance? - ->
      </ul><P></li> -->

  <li><a NAME="coltbl"></a><b>Collocation Table</b> -- An ORB can have
      several listening endpoints.  If there are several ORBs in a
      process and a global collocation table is used, then all objects
      in the same process are considered collocated.  If not, only
      objects reside in the same <em>ORB</em> are considered
      collocated.  You can control the usage of global collocation
      table by passing the <code><a href="Options.html#-ORBCollocation">
      -ORBCollocation </a></code> flag as an argument of <code>
      ORB_init </code> (most often thru the command line flags.) <p>

  <li> <a NAME="profile"></a><b>Forwarding Profile</b> --
      When multiple threads using the same
      <tt>CORBA::Object</tt> and using forwarding, it is necessary to
      protect the forwarding <tt>Profile</tt>, which is part of the
      CORBA::Object, against multiple access. Therefore a mutex lock
      is used by default to ensure proper access. <P>

      Using the switch <tt><a href="Options.html#-ORBProfileLock">
      -ORBProfileLock </a></tt> this policy can be deactivated
      specifying <tt>-ORBProfileLock null</tt>.
      The primary reason for doing this is to improve performance
      when no forwarding is used or no multithreading with access to
      shared <tt>CORBA::Object</tt>'s.  Using a null mutex reduces
      the overhead compared with using a regular mutex
      lock.</li><P>

  <li> <a NAME="orbsvcs"></a><b>orbsvcs Library</b> -- By default, the
      TAO orbsvcs library contains all of the services that TAO
      currently supports. To reduce build time and library size, you
      can exclude unused services. To do that, define a
      <tt>TAO_ORBSVCS</tt> variable using one of these
      approaches:</li><P>

      <ol>
        <li>In your
            <tt>$(ACE_ROOT)/include/makeinclude/platform_macros.GNU
            </tt> file,

        <li>On the make command line, <i>e.g.</i>, <tt>make
            TAO_ORBSVCS=Event</tt>, or

        <li>Set (and export) a <tt>TAO_ORBSVCS</tt> environment variable.
      </ol><p>

      Please see the <code><a
      href="../orbsvcs/orbsvcs/Makefile">ORBSVCS
      Makefile</a></code> for the default setting of
      <code>TAO_ORBSVCS</code>.<p>

      Please note that the Naming Service will always be built, even
      if Naming is not specified in <code>TAO_ORBSVCS</code>.  That's
      because many examples, tests, and presumably applications use it.<p>
</ul>

<hr>
<h3>
<a NAME="examples"></a>Configuration Examples</h3>

The following are common ORB configurations used by TAO applications.<P>

<ul>
  <li>
      <a NAME="reactive"></a>Single-threaded, reactive model.</li> <P>

      <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" >
        <tr>
          <th ALIGN=LEFT>Typical Use</th>

          <td>This is the default configuration of TAO, where one
              thread handles requests from multiple clients via a
              single Reactor. It is appropriate when the requests (1)
              take a fixed, relatively uniform amount of time and (2)
              are largely compute bound.&nbsp;</td>
        </tr>

        <tr>
          <th align=left>Number of Threads</th>

          <td>1</td>
        </tr>

        <tr>
          <th align=left>Thread Creator</th>

          <td>OS or whoever creates the main ORB thread in a process.</td>
        </tr>

        <tr>
          <th align=left>Thread task</th>

          <td>The single thread processes all connection requests and
              CORBA messages.</td>
        </tr>

        <tr>
          <th align=left>Options</th>

          <td>The default settings should work just fine.  However,
              you can apply the following options to improve performance:<br>
              <tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
              select_st</tt>, <tt>-ORBInputCDRAllocator null</tt>
              <br><tt>TAO_Server_Strategy_Factory</tt>:
              <tt>-ORBconcurrency reactive</tt> (default),
              <tt>-ORBPOALock null</tt>
              <br><tt>TAO_Client_Strategy_Factory</tt>:
              <tt>-ORBConnectorLock null</tt></td>
          </td>
        </tr>
      </table>

      <P>Check out the <tt><a href="../examples/Simple/grid/">Grid</a></tt>
      for an example of this configuration. <P>

  <li> <a NAME="tpc"></a>Single ORB, multiple threads, thread-per-connection
      model.</li> <P>

      <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" >
        <tr ALIGN="LEFT">
        <th align=left>Typical Use
        </th>

        <td>This configuration spawns a new thread to serve requests
            from a new connection. This approach works well when
            there are multiple connections active simultaneously and
            each request-per-connection may take a fair amount of
            time to execute.
        </td>
      </tr>

      <tr>
        <th align=left>Number of Threads</th>

        <td>1 thread for the ORB, plus 1 thread for each connection.</td>
      </tr>

      <tr>
        <th align=left>Thread Creator</th>

        <td>Programmer must set up the main thread which the ORB
            lives.  The ORB is responsible to create new threads upon
            new connections.</td>
      </tr>

      <tr>
        <th align=left>Thread task</th>

        <td>The main thread handles new connections and spawns new
            threads for them. Other threads handle requests for
            established connections.</td>
      </tr>

      <tr>
        <th align=left>Options</th>

        <td><tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
            select_mt</tt> (default) or other thread-safe platform specific
            reactors.<br>
            <br><tt>TAO_Server_Strategy_Factory</tt>:
            <tt>-ORBConcurrency thread-per-connection</tt></td>
      </tr>
    </table>
    <P>
    <tt><a href="../performance-tests/Cubit/TAO/IDL_Cubit/">IDL_Cubit</a></tt>
    is a good example on using <i>multiple threads, thread-per-connection</i>
    configuration.<P>
<li>
    <P>Multiple threads, multiple ORB, reactive model.<a NAME="multiorb"></a></li><P>

    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
      <tr>
        <th align=left>Typical Use</th>

        <td>In this configuration, there are multiple ORBs in a
            process with multiple threads. Each thread handles requests
            reactively. It's good for hard real-time applications that
            require different thread priorities for the various
            ORBs.</td>
      </tr>

      <tr>
        <th align=left>Number of Threads</th>

        <td>One thread for each ORB.</td>
      </tr>

      <tr>
        <th align=left>Thread Creator</th>

        <td>The main process (thread).</td>
      </tr>

      <tr>
        <th align=left>Thread task</th>

        <td>Service the requests from associating ORB.</td>
      </tr>

      <tr>
        <th align=left>Options</th>

        <td><tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
            select_mt</tt> (default) or other thread-safe platform specific
            reactors.<br>
            <br><tt>TAO_Server_Strategy_Factory</tt>:
            <tt>-ORBConcurrency reactive</tt></td>
      </tr>
</table>
<P>

<li>Multiple threads, multiple ORBs, thread-per-connection model.<a
    NAME="multiorb-tpc"></a></li><P>

    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%">
      <tr align="left">
      <th align=left>Typical Use
      </th>

      <td>This approach provides a range of thread priorities plus connections
          that don't interfere with each others.</td>
    </tr>

    <tr>
      <th align=left>Number of Threads</th>

      <td>One thread for each ORB, plus one thread for each connection.</td>
    </tr>

    <tr>
      <th align=left>Thread Creator</th>

      <td>Main threads creates threads running ORBs. They, in turns,
          create connection handling threads.</td>
    </tr>

    <tr>
      <th align=left>Thread task</th>

      <td>There are threads running ORB's event loops which handle
          connection requests and handler threads which service
          requests form establiched connections.</td>
    </tr>

    <tr>
      <th align=left>Options</th>

      <td><tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
            select_mt</tt> (default) or other thread-safe platform specific
            reactors.<br>
          <br><tt>TAO_Server_Strategy_Factory</tt>:
          <tt>-ORBConcurrency thread-per-connection</tt></td>
    </tr>
</table>

<P>
<tt><a href="../performance-tests/Cubit/TAO/MT_Cubit/">MT_Cubit</a>
</tt> is a good example on using <i>multiple threads,
multiple ORBs, and thread-per-connection</i> configuration.<P>
<li>
    <a NAME="tpool"></a>Multiple threads, single ORB, thread-pool model.</li><P>

    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" >
      <tr>
        <th align=left>Typical Use</th>

        <td>This model implements a highly optimized thread pool that leverages
            context switching, and thread creation costs.  In this
            model, the programmer is responsible of spawning a group
            of threads, start up the ORB and then instruct all the threads
            to run the ORB event loop.  When a request comes in, one
            of these waiting threads in the pool will handle the
            request.</td>
      </tr>

      <tr>
        <th align=left>Number of Threads</th>

        <td>Thread for the ORB, plus the number of threads used by the thread pool.</td>
      </tr>

      <tr>
        <th align=left>Thread Creator</th>

        <td>Pre-spawned by the main thread.</td>
      </tr>

      <tr>
        <th align=left>Thread task</th>

        <td>Blocking on the reactor to wait for its turn to handle a request.</td>
      </tr>

      <tr>
        <th align=left>Options</th>

        <td><tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
            tp</tt>.<br>
            <br><tt>TAO_Server_Strategy_Factory</tt>:
            <tt>-ORBConcurrency reactive</tt></td>
      </tr>
    </table>

<P><li>
    Multiple threads, multiple ORBs, thread-pool model.<a NAME="multiorb-tpool"></a>
</li><P>

    <table BORDER=2 CELLSPACING=2 CELLPADDING=0 WIDTH="90%" >
      <tr>
        <th align=left>Typical Use</th>

        <td>This model incorporates the advantage of using thread-pool
            while allowing hard real-time system to handle requests in
            different priority.</td>
      </tr>

      <tr>
        <th align=left>Number of Threads</th>

        <td>One thread for each ORB, plus the total number of threads in all thread pools</td>
      </tr>

      <tr>
        <th align=left>Thread Creator</th>

        <td>Pre-spawned by the main thread.</td>
      </tr>

      <tr>
        <th align=left>Thread task</th>

        <td>Handle incoming request for the ORB event loop it is
            waiting on.</td>
      </tr>
      <tr>
        <th align=left>Options</th>

        <td><tt>TAO_Resource_Factory</tt>: <tt>-ORBReactorType
            tp</tt>.<br>
            <br><tt>TAO_Server_Strategy_Factory</tt>:
            <tt>-ORBConcurrency reactive</tt></td>
      </tr>
</table>
</ul>

<hr>
<h3>
Programming Considerations<a NAME="programming"></a></h3>

There are several ways to pass option flags into TAO's
components. <P>

<ul>

  <li><p>The plain vanilla approach is do nothing.  All TAO components
      use their <a
      href="Options.html">default settings</A>.</p>

  <li><p>The most common use case is to use a file called
      <code>svc.conf</code>.  On most platforms, TAO programs
      automatically search and read in the file.  The disadvantage of
      this approach is you always need a <code>svc.conf</code> file if
      you want to do use non-default configuration.</p>

  <li><p>You can use <code>-ORBSvcConf <em>filename</em></code> to use
      a config file that is not called <code>svc.conf</code>.
      Specifying <code>-ORBSvcConf</code> exclude the reading of
      default <code>svc.conf</code> file.</p>

  <li><p>If you don't want the application users to worry about
      setting up or knowing about <code>svc.conf</code> files, you can
      call <code>TAO_Internal::default_svc_conf_entries()</code>
      before calling the first <code>ORB_init()</code> in your program
      to set up the default svc.conf entries.  In this case, if a TAO
      application cannot find a svc.conf file, it will configure TAO's
      components using the default settings.  You can still use a
      <code>svc.conf</code> file or use <code>-ORBSvcConf</code>
      option to tune the program.<P>

  <li><p>TAO programs evaluate the configuration settings in the following
      order,</p>

      <ol>
        <li>File specified in <code>-ORBSvcConf</code> command-line
            option, if one exist.  Otherwise, the
            <code>svc.conf</code> in the start-up directory will be
            evaluated, if one exist.
        <li>Default entries set by
            <code>TAO_Internal::default_svc_conf_entries()</code>, if
            ones exist.
        <li>Default configuration as specified in <a
            href="Options.html">this document</a>.
      </ol>

      <p>Notice that the first encountered component settings are
      always the ones take effect.  For example, if you set the entries
      for <code>Resource_Factory</code> and
      <code>Server_Strategy_Factory</code> using
      <code>TAO_Internal::default_svc_conf_entries()</code> in a
      program and you also have a file called <code>svc.conf</code>
      which has an entry for <code>Resource_Factory</code>.  This
      program will use the entry for <code>Resource_Factory</code> in
      the <code>svc.conf</code> file, the entry for
      <code>Server_Strategy_Factory</code> set in the program, and the
      in-stock <code>Client_Strategy_Factory</code> that TAO defines. <P>

  <li><p>Some platforms do not support reading of <code>svc.conf</code>
      files or you would rather not to use the feature.  In this case,
      you must define <code>TAO_PLATFORM_SVC_CONF_FILE_NOTSUP</code>
      in your ACE <code>config.h</code> file and recompile TAO
      library.  In this case, a TAO program will not try to search for
      the default <code>svc.conf</code> file.  However, if platform
      support, you can still use <code>-ORBSvcConf</code> to change
      the program behavior temporarily.</p>

      <p>On these platform, you can alter the default settings for
      TAO components by defining the following macros in your
      <code>config.h</code> file:</p>

      <ul>
        <li><code>TAO_DEFAULT_RESOURCE_FACTORY_ARGS</code>
        <li><code>TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS</code>
        <li><code>TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS</code>
      </ul>

      <p>The ACE Makefiles <code>fakesvcconf</code> flag can be
      used to define <code>TAO_PLATFORM_SVC_CONF_FILE_NOTSUP</code>.
      To define that macro, just add <code>fakesvcconf=1</code> to
      your <code>make</code> invocation.

      <p>See <a href="../tao/orbconf.h"><code>orbconf.h</code></a> for
      an example.
</ul>

<hr>
<h3>
Configuration for homogenous systems<a NAME="homogenous"></a></h3>

<ul>
  <LI><b>Compile-time options</b><a NAME="homogenous_compile"></a>
      <p>Many real-time applications run on homogenous environments, TAO (and
      ACE) can take advantage of this fact by simplifying the server side demarshaling;
      to enable this feature you have to edit the <tt>$ACE_ROOT/ace/OS.h</tt>
      file and enable the macro <font size=-1>ACE</font><tt>_DISABLE_SWAP_ON_READ</tt>.
      <p>In this systems it is also common that server and the client startup
      and shutdown simultaneously, in those circumstances there is no need to
      check the timestamps in the POA, another macro (<tt>POA_NO_TIMESTAMP</tt>)
      can be used for this purpose.
      <p>Users running in embebbed systems may also need to modify the default
      options for TAO, the macros <tt>TAO_DEFAULT_RESOURCE_FACTORY_ARGS</tt>,
      <tt>TAO_DEFAULT_CLIENT_STRATEGY_FACTORY_ARGS</tt> and <tt>TAO_DEFAULT_SERVER_STRATEGY_FACTORY_ARGS</tt>
      can be used for those purposes. If the footprint size is an issue users
      may consider writing custom strategy factories that only create the right
      strategies, this eliminates the parsing code for the different options.

      <p>
  <LI><b>Run-time options</b><a NAME="homogenous_runtime"></a>
      <p>If the only ORB running is TAO and there is no need to be IIOP interoperable
      the option <tt>-ORBGIOPlite</tt> can be used to reduce the message size
      and the processing time.
      <p>Unix systems that support local IPC (formerly known as Unix domain
      sockets) can take advantage of TAO's UIOP pluggable transport protocol
      to improve performance considerably.  To use TAO's UIOP pluggable
      protocol, simply specify a UIOP endpoint on the command line using
      the <tt>-ORBEndpoint</tt> option described in the
      <A HREF="Options.html">options</A> documentation.  Further performance
      improvement can be achieved by using the UIOP protocol in combination
      with the <tt>-ORBGIOPlite</tt> option.  Additional information about
      TAO's UIOP pluggable protocol can be found in the
      <A HREF="releasenotes/index.html#pp">release notes</A>.
      <p>Some embedded systems run without the benefit of a DNS server, in that
      case they can use the <tt>-ORBDottedDecimalAddresses</tt> option; the ORB
      will avoid the use of hostnames in the profiles it generates, thus clients
      don't need to do any name resolution. Use the compile-time define
      <tt>TAO_USES_DOTTED_DECIMAL_ADDRESSES</tt> in
      <tt>$TAO_ROOT/tao/orbconf.h</tt> to make this the default behavior.
</ul>

<hr>
<h3>Configuration Suggestions</h3>

Choosing the right configuration is hard and, of course, depends on your
application. In the following section we will attempt to describe some
motivations for features in TAO, hopefully that can guide you through the
choice of your configuration options.
<ul>

  <LI><b>ORB-per-thread</b> -- The main motivation behind this options is to
      minimize priority invertion, since threads share no ORB resources no locking
      is required and thus, priority is preserved in most cases (assuming proper
      support from the OS). If you are not too concerned about priority inversion
      try to use a single ORB, using ORB-per-thread has some tradeoffs (like
      calling ORB_init on each thread, activation of a servant is more complicated,
      etc.) Some of the problems, can be minimized, but they require even more
      careful analysis.
      <p>As the reader will note this is a delicate configuration option, the
      rule of thumb should be <b>not</b> to use ORB-per-thread unless it is really
      required. <P>

  <li>

      <b>Collocation tables</b> -- Why would an application not want to
      use the global collocation table?  Because a collocated method
      invocation is run in the client's thread-of-control.  If objects
      are to serve requests only at a well
      known priority the application can be configured with the
      ORB-per-thread option, and the object is activated only in the thread
      (ORB) corresponding to the desired priority.  But using a global table
      would subert the priority assignment (because calls would run at the
      priority of the client).</li><P>

  <li> <b>Single-threaded vs. Multi-threaded Connection Handlers</b>
      -- The
      <tt>Client_Connection_Handler</tt> is the component in TAO that writes
      the requests to the underlying transport socket; this is also the
      component that reads the response back from the server.</li>

      <p>

      While waiting for this response new requests to the local ORB can
      arrive, this is the so-called nested upcall support. TAO supports two
      mechanisms for handling nested upcalls, the default uses the
      leader-follower model to allow multiple threads to wait on a single
      reactor for several concurrent requests; sometimes this configuration
      can be an overkill, if only one thread is using a reactor at the same
      time a lighter weight implementation can be used.  <p>This
      configuration is controlled by the <tt>-ORBClientConnectionHandler</tt>
      option, good opportunities to use this option are:<P>

      <ul>
        <li> Single threaded servers</li>

        <li> Servers running in ORB-per-thread mode (pseudo single
            threaded.)</li>

        <li> Pure clients that will never receive a request</li>
      </ul><P>

<li>
    <b>Allocator for input CDR streams</b> -- Normally the application has no
    access to this buffer, and it is only used on the demarshaling of arguments
    (or results). It is almost always better to use the "<tt>-ORBInputCDRAllocator
    null</tt>" option since it will allocate memory from a thread specific allocator
    and it will not need locks to manage that memory.</li>

    <p>In some cases the user <i>may</i> gain access to the CDR stream
    buffer: TAO makes no copies when demarshaling octet sequences, instead
    the octet sequence simply points to the CDR buffer, since the octet
    sequence does not own this buffer a copy must be made if the user
    wants to keep the buffer after the upcall.

    <p>The user can, however, increase the reference count on the CDR
    stream buffer, thus allowing her to extend the lifetime of this
    buffer. Still passing this buffer to another thread and attempting to
    release it in that thread will result in some memory leak or
    corruption. Users willing to use this feature of TAO can still do so,
    <b>if</b> they use a global allocator for their input CDR stream, but
    that will introduce extra locking on the critical path.  <p>As the
    reader can see this is an option that has limited applicability and
    requires careful consideration of the tradeoffs involved.
</ul>

<hr>
<p>Back to the TAO <a href="components.html">components documentation</a>.<!--#include virtual="/~schmidt/cgi-sig.html" -->
</body>
</html>