diff options
Diffstat (limited to 'TAO/docs/ec_options.html')
| -rw-r--r-- | TAO/docs/ec_options.html | 355 |
1 files changed, 0 insertions, 355 deletions
diff --git a/TAO/docs/ec_options.html b/TAO/docs/ec_options.html deleted file mode 100644 index 06c8c54d8ed..00000000000 --- a/TAO/docs/ec_options.html +++ /dev/null @@ -1,355 +0,0 @@ -<!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>Overview</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>The current implementation provides a default implementation - for this Factory, this document describes the options used by - this default implementation. - </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 ....." -</PRE> - - <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. A <EM>reactive</EM> strategy will use the - same thread that received the event from the supplier to - push the event to all the consumers, - the <EM>priority</EM> strategy will use a prioritized pool - of threads and will query the scheduling service to select - the thread that will dispatch each event; - the <EM>mt</EM> strategy will also use a pool of threads, - but the thread to dispatch is randomly selected. - </TD> - </TR> - - <!-- <TR NAME="ECDispatchingThreads"> --> - <TR> - <TD><CODE>-ECDispatchingThreads</CODE> - <EM>number_of_threads</EM> - </TD> - <TD>Select the number of threads used bythe <EM>mt</EM> - dispatching strategy. - </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, conjunctions and timeouts based on the - subscriptions passed by the consumer during the connect - call. - The <EM>priority</EM> filtering strategy supports the same - features, 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 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 specially 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. - </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 enables this feature. - <BR><B>NOTE:<B> The default is to have the feature disabled. - </TD> - </TR> - - <!-- <TR NAME="ECPushSupplierSet"> --> - <TR> - <TD><CODE>-ECPushSupplierSet</CODE> - <EM>strategy</EM> - </TD> - <TD><P>Consumers can connect and disconnect from the event - channel as part of push to one consumer; - changing the set of consumers as a result of such an - operation would invalidate the iterators used by the event - channel to dispatch to the relevant consumers. - There are several ways to handle this problem, for example - a copy of the set could be made <I>before</I> initiating - the dispatch, or only if there is a change on the set - <I>during</I> the dispatch. - If the dispatching strategy is not reactive then it is - possible to lock the set of consumers during the duration - of the dispatch operation, the change in the subscriptions - will be held until the event is completely processed. - Finally the subscription change could be delayed until the - event is fully processed and there is no risk of - invalidating an iterator. - </P> - <P>All this strategies have merits under different - circumstances, the user can select the right one for his - application using this option. - The <EM>immediate</EM> strategy will perform any changes - on the consumer set immediately, simply using a lock to - synchronize access. The <EM>delayed</EM> operation will - wait until there are no threads iterating over the set - to perform any modifications on it. - The <EM>immediate_st</EM> simply performs the - modications without taking any locks, it is useful for - single threaded applications that do not receive changes - are part of an upcall (for example: if there are no - collocated consumers). - </P> - </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="ECConsumerAdminLock"> --> - <TR> - <TD><CODE>-ECConsumerAdminLock</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 - ConsumerAdmin state. - </TD> - </TR> - - <!-- <TR NAME="ECSupplierAdminLock"> --> - <TR> - <TD><CODE>-ECSupplierAdminLock</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 - SupplierAdmin state. - </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; - this 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_reconnecto</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_reconnecto</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 using the delayed strategy to update - ProxyPushSupplier sets this flag controls the maximum - number of thread that can simultaneously iterate over the - set before blocking. - It can be used to avoid starvation in delayed updates on - the set. - </TD> - </TR> - - <TR><TD><CODE>max_write_delay</CODE></TD> - <TD>When using the delayed strategy to update - ProxyPushSupplier sets 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 set. - </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> - </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: Fri Jul 2 11:24:48 CDT 1999 -<!-- hhmts end --> - </body> -</html> |