Real-time Event Channel Configuration

Overview

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.

The current implementation provides a default implementation for this Factory, this document describes the options used by this default implementation.

The configuration file

The real-time event channel uses the same service configurator file that the ORB uses, the default name for this file is svc.conf, but the ORB option -ORBSvcConf 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:

# Comments go here...
# More comments if you want to...
static EC_Factory "-ECFiltering basic ....."

All the event service factory options start with -EC

The options

Option Description
-ECDispatching dispatching_strategy Select the dispatching strategy used by the real-time event service. A reactive strategy will use the same thread that received the event from the supplier to push the event to all the consumers, the priority strategy will use a prioritized pool of threads and will query the scheduling service to select the thread that will dispatch each event; the mt strategy will also use a pool of threads, but the thread to dispatch is randomly selected.
-ECDispatchingThreads number_of_threads Select the number of threads used bythe mt dispatching strategy.
-ECFiltering consumer_filtering_strategy Select the filtering strategy used by the consumers. The null filtering strategy will build trivial filters for all consumers. The basic filtering strategy supports disjunction, conjunctions and timeouts based on the subscriptions passed by the consumer during the connect call. The priority filtering strategy supports the same features, but it also collaborates with the scheduling service to build the dependency graph.
-ECSupplierFiltering supplier_filtering_strategy 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 null then a global collection of consumers is maintained and each event is filtered by each consumer. If the strategy is per-supplier 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.
-ECTimeout timeout_strategy A consumer can request that the event channel generate periodic or oneshot timeout events. This option controls the strategy to generate the timeouts, using reactive the same reactor used for the ORB is used by the event service. The priority strategy uses a prioritized group of threads, timeouts with higher rate are generated by threads of higher priority.
NOTE: The priority strategy is not implemented
-ECObserver observer 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 null strategy; whereas the basic strategy provides a simple, yet efficient implementation.
-ECScheduling scheduling_strategy The event channel can collaborate with the scheduling service to build the dependency list between the consumers and the suppliers. If the null scheduling strategy is selected this feature is disabled, the priority strategy enables this feature.
NOTE: The default is to have the feature disabled.
-ECPushSupplierSet strategy

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 before initiating the dispatch, or only if there is a change on the set during 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.

All this strategies have merits under different circumstances, the user can select the right one for his application using this option. The immediate strategy will perform any changes on the consumer set immediately, simply using a lock to synchronize access. The delayed operation will wait until there are no threads iterating over the set to perform any modifications on it. The immediate_st 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).

-ECProxyConsumerLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the ProxyPushConsumer state.
-ECProxySupplierLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the ProxyPushSupplier state.
-ECConsumerAdminLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the ConsumerAdmin state.
-ECSupplierAdminLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the SupplierAdmin state.

The constructor

The TAO_EC_Event_Channel class implements the RtecEventChannelAdmin::EventChannel interface; this class takes one mandatory and two optional parameters in its constructor:

  TAO_EC_Event_Channel (const TAO_EC_Event_Channel_Attributes& attributes,
                        TAO_EC_Factory* factory = 0,
                        int own_factory = 0);

The factory is an optional parameter to override the default strategy factory used by the event channel, the event channel will destroy the factory if the own_factory argument is true.

The attributes 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 IMPLICIT_ACTIVATION and the SYSTEM_ID policies (as the RootPOA does).

AttributeDescription
consumer_reconnecto If the attribute is not zero then the same consumer can call connect_push_consumer on its ProxyPushSupplier multiple times to change its subscriptions; this is usually more efficient that disconnecting and connecting again.
supplier_reconnecto If the attribute is not zero then the same supplier can call connect_push_supplier on its ProxyPushConsumer multiple times to change its publications; this is usually more efficient that disconnecting and connecting again.
busy_hwm 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.
max_write_delay When using the delayed strategy to update ProxyPushSupplier sets this flag controls the maximum number of threads that will initiate dispatching after 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.
scheduler 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.


Back to the TAO components documentation.

Carlos O'Ryan
Last modified: Fri Jul 2 11:24:48 CDT 1999