COS Event Channel Configuration

Run-time Configuration

The new implementation of the COS Event Service 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. Users can define their own implementation, with new ad-hoc strategies or with pre-selected strategies.

The configuration file

The COS 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 CEC_Factory "-CECDispatching reactive ....."

All the event service factory options start with -CEC

The options

Option Description
-CECDispatching dispatching_strategy Select the dispatching strategy used by the COS 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.
-CECDispatchingThreads number_of_threads Select the number of threads used bythe mt dispatching strategy.
-CECProxyConsumerLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the ProxyPushConsumer state.
-CECProxySupplierLock lock_type Select the lock type (null, thread or recursive) to synchronize access to the ProxyPushSupplier state.
-CECORBId orbid 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.
-CECConsumerControl policy Select the consumer control policy (null or reactive) to detect and discard broken consumer proxies.
-CECSupplierControl policy Select the supplier control policy (null or reactive) to detect and discard broken supplier proxies.
-CECConsumerPeriod period Set the period (in microseconds) used by the reactive consumer control policy to poll the state of the consumer proxies.
-CECSupplierPeriod period Set the period (in microseconds) used by the reactive supplier control policy to poll the state of the supplier proxies.
-CECReactivePullingPeriod period Set the period (in microseconds) used by the reactive pulling strategy to poll all the PullSuppliers for an event.
-CECProxyConsumerCollection flag[:flags]

Configure the data structure and strategies used to implement collections of ProxyPushConsumers and ProxyPullConsumers. The argument is a colon separated list of flags, with the following semantics: <
FlagDescription
MT Use regular mutexes and/or condition variables for serialization. ST Use null mutexes and/or condition variables for serialization. LIST 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). RB_TREE 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). IMMEDIATE 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. COPY_ON_READ 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. COPY_ON_WRITE UNIMPLEMENTED Similar to the previous one, but the copy is only performed when needed. DELAYED 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.

-CECProxySupplierCollection flag[:flags]

Configure the data structure and strategies used to implement collections of ProxyPushSupplier and ProxyPullSupplier objects. Use the same arguments as with the CECProxyConsumerCollection option.

The constructor

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

  TAO_EC_EventChannel (const TAO_CEC_EventChannel_Attributes& attributes,
                       TAO_CEC_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, ProxyPushSupplier, ProxyPullConsumer and the ProxyPullSupplier objects; this POAs must have the IMPLICIT_ACTIVATION and the SYSTEM_ID policies (as the RootPOA does).

AttributeDescription
consumer_reconnect 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_reconnect 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.


Back to the TAO components documentation.

Carlos O'Ryan
Last modified: Tue Feb 1 13:50:47 PST 2000