Wed Dec 6 23:52:48 2000 Pradeep Gore <pradeep@cs.wustl.edu>

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  <pradeep@cs.wustl.edu>
+
+	* orbsvcs/orbsvcs/Notify/Notify_ProxyConsumer_T.cpp:
+	  The <init> 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 <sarabjeet_duhra@hp.com> for
+	  reporting the problem with the -MTListenerEval option
+	
 Wed Dec  6 16:20:36 2000  Darrell Brunsch <brunsch@uci.edu>
 
         * 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;
@@ -312,6 +326,11 @@ Notify_Service::parse_args(int argc, char *argv[])
 
           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)
         {
           ACE_DEBUG((LM_DEBUG,
@@ -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<SERVANT_TYPE>::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:
 -----