From 22af0a32ef126d06e2ea2f824efaaa642f18e639 Mon Sep 17 00:00:00 2001 From: pradeep Date: Thu, 7 Dec 2000 05:56:38 +0000 Subject: Wed Dec 6 23:52:48 2000 Pradeep Gore --- TAO/ChangeLogs/ChangeLog-02a | 16 ++++++ TAO/orbsvcs/Notify_Service/Notify_Service.cpp | 45 ++++++++++++++- TAO/orbsvcs/Notify_Service/Notify_Service.h | 30 ++++++++++ TAO/orbsvcs/Notify_Service/README | 19 ++++++- .../orbsvcs/Notify/Notify_ProxyConsumer_T.cpp | 2 +- TAO/orbsvcs/orbsvcs/Notify/README | 64 +++++++++++++++------- 6 files changed, 152 insertions(+), 24 deletions(-) diff --git a/TAO/ChangeLogs/ChangeLog-02a b/TAO/ChangeLogs/ChangeLog-02a index e4f33c855af..24e48d8b947 100644 --- a/TAO/ChangeLogs/ChangeLog-02a +++ b/TAO/ChangeLogs/ChangeLog-02a @@ -1,3 +1,19 @@ +Wed Dec 6 23:52:48 2000 Pradeep Gore + + * orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp: + The method was creating a "event listener" task instead of a + "event source" task. This was causing the cmd line options to break. + * orbsvcs/Notify_Service/Notify_Service.{h.cpp}: + Added a new option to specify worker threads when the Notify + Service is run with a TP reactor. + * orbsvcs/Notify_Service/README: + Updated the usage section to show how the "-Notify_TPReactor"option. + * orbsvcs/orbsvcs/Notify/README: + Updated with some explaination of the various MT options for the + Notify. + Thanks to Sarabjeet Duhra for + reporting the problem with the -MTListenerEval option + Wed Dec 6 16:20:36 2000 Darrell Brunsch * tests/Faults/Faults.dsw: diff --git a/TAO/orbsvcs/Notify_Service/Notify_Service.cpp b/TAO/orbsvcs/Notify_Service/Notify_Service.cpp index abaf33d87e6..1422e94f302 100644 --- a/TAO/orbsvcs/Notify_Service/Notify_Service.cpp +++ b/TAO/orbsvcs/Notify_Service/Notify_Service.cpp @@ -16,7 +16,8 @@ Notify_Service::Notify_Service (void) ior_output_file_ (0), notify_factory_name_ (NOTIFY_KEY), notify_channel_name_ (NOTIFY_CHANNEL_NAME), - register_event_channel_ (0) + register_event_channel_ (0), + nthreads_ (0) { // No-Op. } @@ -59,6 +60,16 @@ Notify_Service::init_ORB (int& argc, char *argv [], poa_manager->activate (ACE_TRY_ENV); ACE_CHECK_RETURN (-1); + if (this->nthreads_ > 0) // we have chosen to run in a thread pool. + { + ACE_DEBUG ((LM_DEBUG, "Running %d server threads\n", this->nthreads_)); + worker_.orb (this->orb_.in ()); + + if (worker_.activate (THR_NEW_LWP | THR_JOINABLE, + this->nthreads_) != 0) + ACE_ERROR_RETURN ((LM_ERROR, + "Cannot activate client threads\n"), -1); + } return 0; } @@ -221,7 +232,10 @@ Notify_Service::run (void) { ACE_DEBUG ((LM_DEBUG, "%s: Running the Notification Service\n", __FILE__)); - if (this->orb_->run () == -1) + + if (this->nthreads_ > 0) + worker_.thr_mgr ()->wait (); + else if (this->orb_->run () == -1) ACE_ERROR_RETURN ((LM_ERROR, "%p\n", "run"), -1); return 0; @@ -310,6 +324,11 @@ Notify_Service::parse_args(int argc, char *argv[]) this->register_event_channel_ = 1; // Register one EC with naming. + arg_shifter.consume_arg (); + } + else if ((current_arg = arg_shifter.get_the_parameter ("-Notify_TPReactor"))) + { + this->nthreads_ = ACE_OS::atoi (current_arg); arg_shifter.consume_arg (); } else if (arg_shifter.cur_arg_strncasecmp ("-?") == 0) @@ -321,6 +340,7 @@ Notify_Service::parse_args(int argc, char *argv[]) "-Channel -ChannelName channel_name\n" "default: %s -Factory NotifyEventChannelFactory " "-NameSvc -Channel NotifyEventChannel\n", + "-Notify_TPReactor [threads]\n", argv[0], argv[0])); arg_shifter.consume_arg (); @@ -335,6 +355,27 @@ Notify_Service::parse_args(int argc, char *argv[]) return 0; } +/*****************************************************************/ + +Worker::Worker (void) +{ +} + +void +Worker::orb (CORBA::ORB_ptr orb) +{ + orb_ = CORBA::ORB::_duplicate (orb); +} + +int +Worker::svc (void) +{ + this->orb_->run (); + return 0; +} + +// **************************************************************** + int main (int argc, char *argv[]) { diff --git a/TAO/orbsvcs/Notify_Service/Notify_Service.h b/TAO/orbsvcs/Notify_Service/Notify_Service.h index 1f5f0c02d15..951d559d356 100644 --- a/TAO/orbsvcs/Notify_Service/Notify_Service.h +++ b/TAO/orbsvcs/Notify_Service/Notify_Service.h @@ -20,10 +20,34 @@ #include "tao/PortableServer/PortableServer.h" #include "orbsvcs/CosNotifyChannelAdminC.h" #include "orbsvcs/CosNamingC.h" +#include "ace/Task.h" #define NOTIFY_KEY "NotifyEventChannelFactory" #define NOTIFY_CHANNEL_NAME "NotifyEventChannel" + +class Worker : public ACE_Task_Base +{ + // = TITLE + // Run a server thread + // + // = DESCRIPTION + // Use the ACE_Task_Base class to run server threads + // +public: + Worker (void); + // ctor + + void orb (CORBA::ORB_ptr orb); + + virtual int svc (void); + // The thread entry point. + +private: + CORBA::ORB_var orb_; + // The orb +}; + class Notify_Service { // = TITLE @@ -102,5 +126,11 @@ protected: CosNaming::NamingContext_var naming_; // A naming context. + + Worker worker_; + // Worker for TP reactor mode. + + int nthreads_; + // Number of worker threads. }; #endif /* NOTIFY_SERVICE_H */ diff --git a/TAO/orbsvcs/Notify_Service/README b/TAO/orbsvcs/Notify_Service/README index e1c81fa65fb..3a32ca42431 100644 --- a/TAO/orbsvcs/Notify_Service/README +++ b/TAO/orbsvcs/Notify_Service/README @@ -39,6 +39,15 @@ Command line arguments: Naming Service. The default is "NotifyEventChannel". +"-Notify_TPReactor [threads]": Tells the Notify Service that the ORB + will use a TP reactor and specifies the + number of worker threads to utilize. + + +Note that the svc.conf file must instruct the oRB to use a TP reactor +e.g. static Resource_Factory "-ORBReactorType tp -ORBReactorMaskSignals 0" +Please look up the ORB configuration options to get more information +on this. Running the Service: ------------------- @@ -79,7 +88,15 @@ The "Notify_Default_Event_Manager_Objects_Factory" service object accepts the fo "-LookupThreads [thread_count]" : How many lookup threads. "-MTListenerEval" : Enable MT proxy supplier (listener) filter evaluation. "-ListenerThreads" : How many threads for listener filter evaluation. - +"-Notify_TPReactor [threads]" : Tells the service that the ORB + is using a TP reactor and + specifies the number of worker + threads to deploy. + Note that you might have to + specify the TP reactor in the + svc.conf file. + (see the ORB configutrations + for details on this) e.g. svc.conf static Notify_Default_Event_Manager_Objects_Factory "-MTSourceEval -MTDispatching -DispatchingThreads 2" diff --git a/TAO/orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp b/TAO/orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp index 4fa26b49be7..806cc2b5620 100644 --- a/TAO/orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp +++ b/TAO/orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp @@ -38,7 +38,7 @@ TAO_Notify_ProxyConsumer::init (CosNotifyChannelAdmin::ProxyID pro TAO_Notify_Factory::get_event_manager_objects_factory (); this->filter_eval_task_ = - event_manager_objects_factory->create_listener_eval_task (ACE_TRY_ENV); + event_manager_objects_factory->create_source_eval_task (ACE_TRY_ENV); ACE_CHECK; // Get hold of the admin properties. diff --git a/TAO/orbsvcs/orbsvcs/Notify/README b/TAO/orbsvcs/orbsvcs/Notify/README index 2b060280bd9..05684cec2d4 100644 --- a/TAO/orbsvcs/orbsvcs/Notify/README +++ b/TAO/orbsvcs/orbsvcs/Notify/README @@ -3,32 +3,56 @@ $Id$ README for the Notification Service ----------------------------------- -# @@ Pradeep: do you have a document that describes the internals of -# the service? If not, this is a good place to write that down, -# and a good start for the paper... +Implementation notes +-------------------- -The following interfaces have been implemented: -# @@ Pradeep it said 'grammer' it is 'grammar'... -CosNotifyFilter::Filter (supports the Trader TCL grammar) -CosNotifyFilter::FilterFactory +Here is a brief description of the MT options for the Notify Service. +The motivation for adding these "knobs" is give the user a chance to +fine tune his/her thread requirements in the Service at its +bottlenecks. These bottlenecks are at filter evaluation and in the two +way push to consumers. These are the points at which the Event Channel +has to interact with remote objects whose implementation is unknown to +the Event Channel. e.g. if a consumer decided to execute a tight loop +in its push method, it would block the entire event channel if it was +single threaded. By depllying a thread pool to perform dispatching +events to consumers - we can alleviate this problem. -CosNotifyChannelAdmin::ProxyPushConsumer -CosNotifyChannelAdmin::StructuredProxyPushConsumer -CosNotifyChannelAdmin::SequenceProxyPushConsumer +[Also read the $TAO_ROOT/orbsvcs/Notify_Service/README for a proper +description of how to specify these parameters.] -CosNotifyChannelAdmin::ProxyPushSupplier -CosNotifyChannelAdmin::StructuredProxyPushSupplier -CosNotifyChannelAdmin::SequenceProxyPushSupplier (push not implemented) +-MTDispatching +Consider a Notify service running with just one thread, namely the main. +In this case when the event channel dispatches an event to a consumer (by +calling its push method) all other consumers will be blocked, waiting for +their push methods to be invoked. To decouple the consumers from one +another we can deploy dispatching threads using this option. -CosNotifyChannelAdmin::ConsumerAdmin -CosNotifyChannelAdmin::SupplierAdmin -CosNotifyChannelAdmin::EventChannel -Work in progress: ----------------- +-MTListenerEval +In the design of the Notify, all proxy suppliers are modelled as +"listeners". i,e. they listen for events from the event manager. +The MListenerEval option allows us to deploy a thread pool per listener +for filter evaluation. So, if you have big or remote filters associated +with your proxy suppliers you would want to set this option. again the +intent is to decouple the processing time for filter evaluation from rest +of the activities in the event channel. +as it stands now, if you were to set this option, there would be a thread +pool for *every* proxy supplier in the EC. what i would have liked to do +is to be able to set this option as a QoS property so that the thread pool +is set programatically at run time. + + +-MTSourceEval +Similarly, this option is used to deploy a thread pool per proxy consumer +to evaluate filters attached with it. The proxy consumers are modelled as +event sources - supplying events to the event manager. again this will set +a thread pool per proxy consumer. + +-MTLookup +This option allows us to set a common thread pool for *all* proxy +suppliers (versus a dedicated thread pool for each proxy supplier via the +-MTDispatching option). -* Testing of the features implemented so far. -* Support for QoS properties. Usage: ----- -- cgit v1.2.1