diff options
Diffstat (limited to 'TAO/docs/ec_options.html')
| -rw-r--r-- | TAO/docs/ec_options.html | 907 |
1 files changed, 907 insertions, 0 deletions
diff --git a/TAO/docs/ec_options.html b/TAO/docs/ec_options.html new file mode 100644 index 00000000000..efceece9965 --- /dev/null +++ b/TAO/docs/ec_options.html @@ -0,0 +1,907 @@ +<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +<html> + <head> + <title>Real-Time Event Channel Configuration</title> + <!-- $Id$--> + </head> + + <body> + <CENTER> + <h1>Real-Time Event Channel Configuration</h1> + </CENTER> + + <H3>Configuring the Event Channel at Compilation Time</H3> + + <P>TAO's Real-Time Event Channel can be configured at compilation + time to use a different payload than its default. To do so + there are several options: + </P> + + <UL> + <LI><P>To eliminate the <CODE>CORBA::Any</CODE> field in the + event payload you should define the + <CODE>TAO_LACKS_EVENT_CHANNEL_ANY</CODE> + macro when invoking the IDL compiler. + You can do as follows: +<PRE> +$ cd $TAO_ROOT/orbsvcs/orbsvcs +$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_ANY +</PRE> + </P> + </LI> + <LI><P>Similarly you can eliminate the octet sequence field in + the event payload using: +<PRE> +$ cd $TAO_ROOT/orbsvcs/orbsvcs +$ make TAO_IDLFLAGS=-DTAO_LACKS_EVENT_CHANNEL_OCTET_SEQUENCE +</PRE> + </P> + </LI> + <LI><P>Finally you can provide your own event payload, to do + this you should Replace the contents of the + <CODE>RtecDefaultEventData.idl</CODE> + and define some IDL structure named + <CODE>RtecEventData</CODE>. + For example, you could define you own event type as follows: +<PRE> +// Replace RtecDefaultEventData.idl with this: + +struct RtecEventData +{ + sequence<long> my_event_payload; +}; +</PRE> + </LI> + </UL> + + <H3>Run-time Configuration</H3> + + <P>The new implementation of the real-time event channel uses a + factory to build all the objects and strategies it requires. + The factory can be dynamically loaded using ACE Service + Configurator, this is extremely convenient because the factory + can also parse options in the Service Configurator script file. + </P> + + <P>There are currently several implementations of the factory. + <ul> +<li>The <em>default</em> factory supports all of + the options below and most of the potential values, except as + specifically indicated. +<li> + The <em>sched</em> factory defines new option values as indicated + below that allow the RTES to integrate with the Real-Time + Scheduling Service. Use of the <em>sched</em> factory requires + that you link in the TAO_RTSchedEvent library. +<li> + The <em>tpc</em> (thread per consumer) factory defines new + options values as indicated below. This + strategy is similar to the MT dispatching strategy in that it + separates the thread that receives the push() from a supplier + from the thread that does the eventual push() to the + consumer(s), but it differs from MT in that MT has a pool of + threads pulling from a single queue and ultimately potentially + servicing every consumer, whereas TPC has a queue for <em>each</em> + consumer and, thus, a single thread dedicated to pushing to that + consumer. This insures that a badly-behaved consumer <b>CANNOT</b> + have an adverse effect on the channel or supplier.<br> + To use this new strategy you will have to replace the call in your code + for <code>TAO_EC_Default_Factory::init_svcs()</code> with + <code>TAO_EC_TPC_Factory::init_svcs()</code>. + +<li> The <em>basic</em> and <em>null</em> factories are hard-coded + factories that do not support any configuration options. + They both define simple configurations that may enable some + applications to use the RTES in a smaller footprint. + See the files + <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Null_Factory.h</code> + and <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Basic_Factory.h</code> + for details. + </ul> + </P> + +<h3>Special Topic: Queue Configuration</h3> + <p> + In certain configurations such as <em>mt</em> and <em>tpc</em>, + the RTES implementation uses something called + <code>TAO_EC_Queue</code>, which is an in-memory queue that + separates threads that receive <code>push()</code> invocations + from suppliers from the threads that dispatch + <code>push()</code> invocations to consumers. A user of the + RTES can configure some behaviors of this queue as well as + behaviors when the queue reaches certain trigger points. The + configuration of these behaviors is a combination of + compile-time and run-time specification. + </p> + <p> + The queue itself has two trigger points for the number of + invocations in the queue: + <ul> + <li><em>low-water mark (LWM)</em>, a lower threshold below which the + queue allows more invocations to be placed into the queue; + <li><em>high-water mark (HWM)</em>, an upper threshold above which the + queue prevents more invocations from being added to the queue + </ul> + The values for these can be set at compile time via + <code>TAO_EC_QUEUE_LWM</code> and <code>TAO_EC_QUEUE_HWM</code> + for the low-water mark and high-water mark, respectively. + <p> + In addition, an application can specify what the RTES should do if a + queue reaches the HWM, i.e., fills up. This behavior is encapsulated in a + derivation of an <code>ACE_Service_Object</code>, called + <code>TAO_EC_Queue_Full_Service_Object</code>. The RTES looks + for a service object of a particular name (the default for this + name is in macro TAO_EC_DEFAULT_QUEUE_FULL_SERVICE_OBJECT_NAME, + which is "EC_QueueFullSimpleActions") and invokes + <code>queue_full_action()</code> on the instance. See class + <code>TAO_EC_Simple_Queue_Full_Action</code> in file + <code>$TAO_ROOT/orbsvcs/orbsvcs/Event/EC_Dispatching_Task.h</code> + for an example. This particular example can be configured to + either <em>wait</em> or <em>discard</em> new invocations on + reaching the HWM. + </p> + + <H3>The configuration file</H3> + + <P>The real-time event channel uses the same service configurator + file that the ORB uses, the default name for this file is + <CODE>svc.conf</CODE>, but the ORB option + <CODE>-ORBSvcConf</CODE> can be used to override this. + The format of the file is described in detail in + the service configurator documentation, but the relevant section + for the event channel looks like this: + </P> + +<PRE> +# Comments go here... +# More comments if you want to... +static EC_Factory "-ECFiltering basic ....." +# ...and optionally... +static EC_QueueFullSimpleActions "[wait | discard]" +# ...or you can define your own TAO_EC_Queue_Full_Service_Object, +# give it whatever name you want and use -ECQueueFullServiceObject +# (see below) to specify that object's service configurator tag. +</PRE> + + <p> + The + table below describes all of the options (and values) supported by + these factories. + <P>All the event service factory options start with + <CODE>-EC</CODE></P> + + + <H3>The options</H3> + + <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> + <TR> + <TH>Option</TH> + <TH>Description</TH> + </TR> + + <!-- <TR NAME="ECDispatching"> --> + <TR> + <TD><CODE>-ECDispatching</CODE> + <EM>dispatching_strategy</EM> + </TD> + <TD>Select the dispatching strategy used by the real-time + event service. The <EM>reactive</EM> strategy uses the + same thread that received the event from the supplier to + push the event to all the consumers.<br> + The <EM>priority</EM> strategy (sched factory only) uses + a prioritized pool + of threads and queries the scheduling service to select + the thread that dispatches each event.<br> + The <EM>mt</EM> strategy also uses a pool of threads, + but the thread to dispatch is randomly selected.<br> + <b>Does not apply to the <em>tpc</em> factory.</b> + </TD> + </TR> + + <!-- <TR NAME="ECDispatchingThreads"> --> + <TR> + <TD><CODE>-ECDispatchingThreads</CODE> + <EM>number_of_threads</EM> + </TD> + <TD>Select the number of threads used by the <EM>mt</EM> + dispatching strategy.<br> + <b>Does not apply to the <em>tpc</em> factory.</b> + </TD> + </TR> + <!-- <TR NAME="ECDispatchingThreadFlags"> --> + <TR> + <td><code>-ECDispatchingThreadFlags</code> + <em>thread_flags</em><b>:</b><em>thread_priority</em> + </td> + <td> + Provide flags and priority used for creation of + dispatching threads.<br> + <em>thread_flags</em> is a set of + <code>THR_</code> flags separated by the vertical bar + ('|'), e.g., + <code>THR_BOUND|THR_NEW_LWP|THR_SCOPE_SYSTEM</code>. + <br> + <em>thread_priority</em> is a numeric value indicating the + desired priority at which the thread should be created. + No range checking is performed on the value prior to + passing to the thread creation function. Also note that + priorities are platform-specific, so a valid value for a + given set of flags on one platform may not work with the + same flags on another platform. + </tr> + + <!-- <TR NAME="ECQueueFullServiceObject"> --> + <tr> + <td><code>-ECQueueFullServiceObject</code> + <em>service_object_name</em> + </td> + <td> + Used to specify the name/tag in the service configurator + through which the RTEC should look for a "queue full + service object".<br> + <b>Will only have an effect on dispatch strategies that + use <code>TAO_EC_Queue</code>.</b> + </td> + </tr> + <!-- <TR NAME="ECFiltering"> --> + <TR> + <TD><CODE>-ECFiltering</CODE> + <EM>consumer_filtering_strategy</EM> + </TD> + <TD>Select the filtering strategy used by the consumers. + The <EM>null</EM> filtering strategy will build trivial + filters for all consumers. + The <EM>basic</EM> filtering strategy supports + disjunction, conjunction, logical and, negation, bitmask, + and timeout filters based on the subscriptions passed by + the consumer during the connect call. It only supports limited + nesting of filter groups. + The <EM>prefix</EM> filtering strategy supports + all filter types that the <EM>basic</EM> strategy does + and allows unlimited nesting of filter groups. + When using the <EM>prefix</EM> strategy, the source field of the + group filter must specify the number of children in the group. + The <EM>priority</EM> filtering strategy (sched factory only) + supports the same + features as the <EM>basic</EM> filtering strategy, but it + also collaborates with the scheduling service to build the + dependency graph. + </TD> + </TR> + + <!-- <TR NAME="ECSupplierFiltering"> --> + <TR> + <TD><CODE>-ECSupplierFiltering</CODE> + <EM>supplier_filtering_strategy</EM> + </TD> + <TD>The event channel can also perform some filtering close + to the suppliers by minimizing the number of consumers + that are tested for given event. + If the strategy is <EM>null</EM> then a global collection + of consumers is maintained and each event is filtered by + each consumer. + If the strategy is <EM>per-supplier</EM> then the EC uses + the supplier publications and the consumer subscriptions + to determine which consumers could potentially be + interested in events for each supplier. + This set of consumers is usually smaller than the complete + set and it is thus faster to traverse it, but keeping more + collections of consumers increases the connection and + disconnection time as well as the memory requirements. + </TD> + </TR> + + <!-- <TR NAME="ECTimeout"> --> + <TR> + <TD><CODE>-ECTimeout</CODE> + <EM>timeout_strategy</EM> + </TD> + <TD>A consumer can request that the event channel generate + periodic or oneshot timeout events. + This option controls the strategy to generate the + timeouts, + using <EM>reactive</EM> the same reactor used for the ORB + is used by the event service. + The <EM>priority</EM> strategy (sched factory only) uses a + prioritized group of + threads, timeouts with higher rate are generated by + threads of higher priority. + <BR><B>NOTE: The <EM>priority</EM> strategy is not + implemented</B> + </TD> + </TR> + + <!-- <TR NAME="ECObserver"> --> + <TR> + <TD><CODE>-ECObserver</CODE> + <EM>observer</EM> + </TD> + <TD>The event channel uses the Observer pattern to report + changes in the subscriptions and publications of its + suppliers and consumers; this is especially useful in the + implementation of event channel gateways. + The user can disable this feature by selecting the + <EM>null</EM> strategy; + whereas the <EM>basic</EM> strategy provides a simple, yet + efficient implementation. <EM>reactive</EM> provides a + strategy in which an observer that is unreachable is removed + from the observer list. + <BR><B>NOTE:<B> The default is to have the feature disabled. + </TD> + </TR> + + <!-- <TR NAME="ECScheduling"> --> + <TR> + <TD><CODE>-ECScheduling</CODE> + <EM>scheduling_strategy</EM> + </TD> + <TD>The event channel can collaborate with the scheduling + service to build the dependency list between the consumers + and the suppliers. + If the <EM>null</EM> scheduling strategy is selected this + feature is disabled, + the <EM>priority</EM> strategy (sched factory only) enables this feature. + <BR><B>NOTE:<B> The default is to have the feature disabled. + </TD> + </TR> + + <!-- <TR NAME="ECProxyConsumerLock"> --> + <TR> + <TD><CODE>-ECProxyConsumerLock</CODE> + <EM>lock_type</EM> + </TD> + <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or + <EM>recursive</EM>) to synchronize access to the + ProxyPushConsumer state. + </TD> + </TR> + + <!-- <TR NAME="ECProxySupplierLock"> --> + <TR> + <TD><CODE>-ECProxySupplierLock</CODE> + <EM>lock_type</EM> + </TD> + <TD>Select the lock type (<EM>null</EM>, <EM>thread</EM> or + <EM>recursive</EM>) to synchronize access to the + ProxyPushSupplier state. + </TD> + </TR> + + <!-- <TR NAME="ECUseORBId"> --> + <TR> + <TD><CODE>-ECUseORBId</CODE> + <EM>orbid</EM> + </TD> + <TD>Set the name of the ORB used by the event service, only + useful in applications that create multiple ORBs and + activate the event service in one of them. + </TD> + </TR> + + <!-- <TR NAME="ECConsumerControl"> --> + <TR> + <TD><CODE>-ECConsumerControl</CODE> + <EM>policy</EM> + </TD> + <TD>Select the consumer control policy (<EM>null</EM> or + <EM>reactive</EM>) to detect and discard broken consumers. + </TD> + </TR> + + <!-- <TR NAME="ECSupplierControl"> --> + <TR> + <TD><CODE>-ECSupplierControl</CODE> + <EM>policy</EM> + </TD> + <TD>Select the supplier control policy (<EM>null</EM> or + <EM>reactive</EM>) to detect and discard broken suppliers. + </TD> + </TR> + + <!-- <TR NAME="ECConsumerControlPeriod"> --> + <TR> + <TD><CODE>-ECConsumerControlPeriod</CODE> + <EM>period</EM> + </TD> + <TD>Set the period (in microseconds) used by the reactive + consumer control policy (set <EM>ECConsumerControl</EM> to + <EM>reactive</EM>) to poll the state of the consumers. + When set to 0 there is no polling but the + reactive strategy is in place. + </TD> + </TR> + + <!-- <TR NAME="ECSupplierControlPeriod"> --> + <TR> + <TD><CODE>-ECSupplierControlPeriod</CODE> + <EM>period</EM> + </TD> + <TD>Set the period (in microseconds) used by the reactive + supplier control policy (set <EM>ECSupplierControl</EM> to + <EM>reactive</EM>) to poll the state of the suppliers. + When set to 0 there is no polling but the + reactive strategy is in place. + </TD> + </TR> + + <!-- <TR NAME="ECConsumerControlTimeout"> --> + <TR> + <TD><CODE>-ECConsumerControlTimeout</CODE> + <EM>timeout</EM> + </TD> + <TD>Set the timeout period (in microseconds) used by the reactive + consumer control policy (set <EM>ECConsumerControl</EM> to + <EM>reactive</EM>) to detect a timeout when polling the state + of the consumers. + </TD> + </TR> + + <!-- <TR NAME="ECSupplierControlTimeout"> --> + <TR> + <TD><CODE>-ECSupplierControlTimeout</CODE> + <EM>timeout</EM> + </TD> + <TD>Set the timeout period (in microseconds) used by the reactive + supplier control policy (set <EM>ECSupplierControl</EM> to + <EM>reactive</EM>) to detect a timeout when polling the state + of the suppliers. + </TD> + </TR> + + <!-- <TR NAME="ECProxyPushConsumerCollection"> --> + <TR> + <TD><CODE>-ECProxyPushConsumerCollection</CODE> + <EM>flag[:flags]</EM> + </TD> + <TD><P>Configure the data structure and strategies used to + implement collections of + <CODE>ProxyPushConsumers</CODE>. + The argument is a colon separated list of flags, with + the following semantics: + <TABLE BORDER="1" CELLSPACING="2" CELLPADDING="0"> + <TR><TH>Flag</TH><TH>Description</TH> + </TR> + <TR> + <TD>MT</TD> + <TD>Use regular mutexes and/or condition + variables for serialization. + </TD> + </tr> + <TR> + <TD>ST</TD> + <TD>Use null mutexes and/or condition + variables for serialization. + </TD> + </tr> + <TR> + <TD>LIST</TD> + <TD>Implement the collection using an ordered list, + fast for iteration (i.e. during event dispatching), + but slow for insertion and removal (i.e. when + clients connect and disconnect from the EC). + </TD> + </tr> + <TR> + <TD>RB_TREE</TD> + <TD>Implement the collection using a Red-Black tree, + slow for iteration (i.e. during event dispatching), + but fast for insertion and removal (i.e. when + clients connect and disconnect from the EC). + </TD> + </tr> + <TR> + <TD>IMMEDIATE</TD> + <TD>Threads block until they can execute a change on + the data structure, the system must use other + approaches to guarantee that the iterators are not + invalidated during event dispatching. For example, + use a separate dispatching thread. Using this option + with the reactive values for any of the + -ECSupplierControl, -ECConsumerControl, or + -ECDispatching options may cause deadlocks. + </TD> + </tr> + <TR> + <TD>COPY_ON_READ</TD> + <TD>Before initiating an iteration to dispatch events + (or similar tasks) a copy of the complete collection + is performed. + This solves most of the synchronization problems, + but introduces a significant source of overhead and + priority inversions on the critical path. + </TD> + </tr> + <TR> + <TD>COPY_ON_WRITE</TD> + <TD>Similar to the previous one, but the copy is only + performed when needed. + </TD> + </tr> + <TR> + <TD>DELAYED</TD> + <TD>Threads that need to change the collection can + detect if that change will invalidate iterators used + by other threads. + If so, the thread posts the change on a queue that + is executed once the collection is no longer in + use. + </TD> + </TR> + </TABLE> + </P> + </TD> + </TR> + + <!-- <TR NAME="ECProxyPushSupplierCollection"> --> + <TR> + <TD><CODE>-ECProxyPushSupplierCollection</CODE> + <EM>flag[:flags]</EM> + </TD> + <TD><P>Configure the data structure and strategies used to + implement collections of <CODE>ProxyPushSupplier</CODE> + objects. + Use the same arguments as with the + <CODE>ECProxyPushConsumerCollection</CODE> option. + </P> + </TD> + </TR> + + <!-- <TR NAME="ECPushSupplierSet"> --> + <TR> + <TD><CODE>-ECPushSupplierSet</CODE> + </TD> + <TD><P>Obsolete option, ignored. + </P> + </TD> + </TR> + + <!-- <TR NAME="ECConsumerAdminLock"> --> + <TR> + <TD><CODE>-ECConsumerAdminLock</CODE> + </TD> + <TD>Obsolete option, ignored in the current version. + </TD> + </TR> + + <!-- <TR NAME="ECSupplierAdminLock"> --> + <TR> + <TD><CODE>-ECSupplierAdminLock</CODE> + </TD> + <TD>Obsolete option, ignored in the current version. + </TD> + </TR> + + <!-- <TR NAME="ECConsumerValidateConnection"> --> + <TR> + <TD><CODE>-ECConsumerValidateConnection</CODE> + <EM>validate_connection: 0 | 1</EM> + </TD> + <TD>When this option is set the connection from the Event Channel + to the consumer will be created during the connect of the + consumer, just before the consumer is added to the consumer + list. By default + the Event Channel will create the connection to the consumer at + the moment the first event is pushed to the consumer. + When the network is heavily loaded during this connect and a new event + is pushed before the connection is establed, a new create connection + request is done. When having very high connection establishment + time (for example running on a WAN) and an interval that is much + smaller than the connection establishment time it is wise to + set this option. Else you get dozens of new connection request + that can result in a stack overflow. Another option is to use BiDIR + GIOP so that there is only one connection between Rtec and consumer + but for this the Rtec and the consumer must be changed to set the + BiDIR Policy, this is not implemented at this moment. + </TD> + </TR> + + </TABLE> + </P> + + <H3>The constructor</H3> + + <P>The <CODE>TAO_EC_Event_Channel</CODE> class implements the + <CODE>RtecEventChannelAdmin::EventChannel</CODE> interface; + this class takes one mandatory and two optional parameters in + its constructor: + </P> + +<PRE> + TAO_EC_Event_Channel (const TAO_EC_Event_Channel_Attributes& attributes, + TAO_EC_Factory* factory = 0, + int own_factory = 0); +</PRE> + + <P>The <CODE>factory</CODE> is an optional parameter to override + the default strategy factory used by the event channel, + the event channel will destroy the factory if the + <CODE>own_factory</CODE> argument is true. + </P> + + <P>The <CODE>attributes</CODE> parameter can be used to fine tune + some of the algorithms and strategies used by the event channel, + the default values are probably OK for most applications. + Notice that the attributes include the POA used to activate the + ConsumerAdmin, SupplierAdmin, ProxyPushConsumer and + ProxyPushSupplier objects; + these POAs must have the <CODE>IMPLICIT_ACTIVATION</CODE> and the + <CODE>SYSTEM_ID</CODE> policies (as the RootPOA does). + </P> + + <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> + <TR><TH>Attribute</TH><TH>Description</TH></TR> + + <TR><TD><CODE>consumer_reconnect</CODE></TD> + <TD>If the attribute is not zero then the same consumer can + call <CODE>connect_push_consumer</CODE> on its + ProxyPushSupplier multiple times to change its + subscriptions; + this is usually more efficient that disconnecting and + connecting again. + </TD> + </TR> + + <TR><TD><CODE>supplier_reconnect</CODE></TD> + <TD>If the attribute is not zero then the same supplier can + call <CODE>connect_push_supplier</CODE> on its + ProxyPushConsumer multiple times to change its + publications; + this is usually more efficient that disconnecting and + connecting again. + </TD> + </TR> + + <TR><TD><CODE>busy_hwm</CODE></TD> + <TD>When the delayed flag is set on proxy collections, + this flag controls the maximum + number of threads that can simultaneously iterate over the + collection before blocking. + It can be used to avoid starvation in delayed updates on + the collection. + </TD> + </TR> + + <TR><TD><CODE>max_write_delay</CODE></TD> + <TD>When the delayed flag is set on proxy collections, + this flag controls the maximum + number of threads that will initiate dispatching + <B>after</B> a change has been posted. + Any thread after that is blocked until the operations are + performed. + It can be used to completely stop starvation of delayed + updates on the collection. + </TD> + </TR> + + <TR><TD><CODE>scheduler</CODE></TD> + <TD>Most configurations of the real-time event channel do + not require an scheduler. + If any of the strategies that require an scheduling + service is selected then this attribute should be set + appropiately. + </TD> + </TR> + + <TR><TD><CODE>supplier_poa</CODE></TD> + <TD>The POA used by the event channel to activate SupplierAdmin + and SupplierProxy objects. + </TD> + </TR> + + <TR><TD><CODE>consumer_poa</CODE></TD> + <TD>The POA used by the event channel to activate ConsumerAdmin + and ConsumerProxy objects. + </TD> + </TR> + + <TR><TD><CODE>disconnect_callbacks</CODE></TD> + <TD>If not zero, then the event channel sends disconnect + callbacks when a disconnect method is called on a Proxy. + For example, if a consumer calls + disconnect_push_supplier() on its proxy the EC + invokes disconnect_push_consumer() on the consumer. + An analogous call is also made for suppliers when this + attribute is set. + By default, these callbacks are not made in this situation. + </TD> + </TR> + </TABLE> + </P> + + <H3>Configuring the IIOP Gateway</H3> + + <P>The <CODE>TAO_EC_Gateway_IIOP_Factory</CODE> is the factory for + the <CODE>TAO_EC_Gateway_IIOP</CODE> class. This factory can be + used to configure the settings of the IIOP Gateway using the + svc.conf file. The contents looks like this: + </P> + +<PRE> +# Comments go here... +# More comments if you want to... +static EC_Gateway_IIOP_Factory "-ECGIIOPConsumerECControl null ....." +</PRE> + + <P>All the IIOP Gateway factory options start with + <CODE>-ECGIIOP</CODE></P> + + <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> + <TR> + <TH>Option</TH> + <TH>Description</TH> + </TR> + + <!-- <TR NAME="ECGIIOPConsumerECControl"> --> + <TR> + <TD><CODE>-ECGIIOPConsumerECControl</CODE> + <EM>policy</EM> + </TD> + <TD>Select the consumer ec control policy (<EM>null</EM> or + <EM>reactive</EM> or <EM>reconnect</EM>) to detect and handle + broken consumer ec's. + </TD> + </TR> + <!-- <TR NAME="ECGIIOPConsumerECControlPeriod"> --> + <TR> + <TD><CODE>-ECGIIOPConsumerECControlPeriod</CODE> + <EM>period</EM> + </TD> + <TD>Set the period (in microseconds) used by the reactive and reconnect + consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to + <EM>reactive</EM> or <EM>reconnect</EM>) to poll the state of the consumer ec. + When set to 0 there is no polling but the + reactive strategy is in place. + </TD> + </TR> + + <!-- <TR NAME="ECGIIOPConsumerECControlTimeout"> --> + <TR> + <TD><CODE>-ECGIIOPConsumerECControlTimeout</CODE> + <EM>timeout</EM> + </TD> + <TD>Set the timeout period (in microseconds) used by the reactive and reconnect + consumer ec control policy (set <EM>ECGIIOPConsumerECControl</EM> to + <EM>reactive</EM> or <EM>reconnect</EM>) to detect a timeout when polling the state + of the consumer ec. + </TD> + </TR> + + <!-- <TR NAME="ECGIIOPUseORBId"> --> + <TR> + <TD><CODE>-ECGIIOPUseORBId</CODE> + <EM>orbid</EM> + </TD> + <TD>Set the name of the ORB used by the event gateway, only + useful in applications that create multiple ORBs and + activate the gateway in one of them. + </TD> + </TR> + + <!-- <TR NAME="ECGIIOPUseTTL"> --> + <TR> + <TD><CODE>-ECGIIOPUseTTL</CODE> + <EM>use_ttl: 0 | 1</EM> + </TD> + <TD>Set whether the IIOP Gateway uses the TTL or not. + This is 1 by default. When set to 0 make sure that + no recursive structure is build between ec's, else an + event can keep looping for ever. Useful when there are no + recursive structures and we want the gateway to + transfer all events independent of their TTL because suppliers + can be unaware about the maximum number of hops. In case + this option is 0, the TTL in the event isn't decremented + by the gateway also. + </TD> + </TR> + + <!-- <TR NAME="ECGIIOPUseConsumerProxyMap"> --> + <TR> + <TD><CODE>-ECGIIOPUseConsumerProxyMap</CODE> + <EM>use_consumer_proxy_map: 0 | 1</EM> + </TD> + <TD>Set whether the IIOP Gateway uses a map with a proxy + push consumer for each unique source id or not. This is 1 + by default meaning that a map is used. When set to 0 the + gateway will just use one proxy push consumer to push + events to the consumer ec. This options is useful when + a lot of different source id's are used but there is no + need for a different proxy push consumer for each source id. + Setting this option to 0 then improves the performance. + </TD> + </TR> + </TABLE> + </P> + + <H3>The commandline arguments</H3> + + The Event_Service executable has several commandline arguments you can use. + The following arguments are available. + + <P><TABLE BORDER="2" CELLSPACING="2" CELLPADDING="0"> + <TR> + <TH>Option</TH> + <TH>Description</TH> + </TR> + + <!-- <TR NAME="-d"> --> + <TR> + <TD><CODE>-n</CODE> + <EM>service_name</EM> + </TD> + <TD>The name with which the Event Service registers itself in the + Naming Service. + </TD> + </TR> + <!-- <TR NAME="-o"> --> + <TR> + <TD><CODE>-o</CODE> + <EM>ior_file_name</EM> + </TD> + <TD>The file to which the IOR of the Event Service will be written. + </TD> + </TR> + + <!-- <TR NAME="-p"> --> + <TR> + <TD><CODE>-p</CODE> + <EM>pid_file_name</EM> + </TD> + <TD>The process id of the Event Service will be written to this + file + </TD> + </TR> + + <!-- <TR NAME="-q"> --> + <TR> + <TD><CODE>-q</CODE> + <EM>ec_object_id</EM> + </TD> + <TD>The object ID for the Event Channel that will be used + when a Persistent IOR is generated + </TD> + </TR> + + <!-- <TR NAME="-b"> --> + <TR> + <TD><CODE>-b</CODE> + <EM></EM> + </TD> + <TD>Use BiDIR GIOP + </TD> + </TR> + + <!-- <TR NAME="-x"> --> + <TR> + <TD><CODE>-x</CODE> + <EM></EM> + </TD> + <TD>Don't register the Event Service to the Naming Service + </TD> + </TR> + + <!-- <TR NAME="-s"> --> + <TR> + <TD><CODE>-s</CODE> + <EM>global|local|none</EM> + </TD> + <TD>Which scheduler should be used. The default is <CODE>none</CODE>. + With <CODE>local</CODE> an in process scheduler is created. With + <CODE>global</CODE> a scheduler is retrieved from the Naming Service + </TD> + </TR> + </TABLE> + </P> + + <P><HR><P> + + Back to the TAO <A HREF="index.html">components documentation</A>. + + <!--#include virtual="/~schmidt/cgi-sig.html" --> + +<!-- <address><a href="mailto:coryan@cs.wustl.edu">Carlos O'Ryan</a></address>--> +<!-- Created: Thu Jul 1 21:44:28 CDT 1999 --> +<!-- hhmts start --> +Last modified: Tue Oct 18 13:13:54 CDT 2005 +<!-- hhmts end --> + </body> +</html> |