Please report new issues athttps://github.com/DOCGroup
the line "this->orb_->orb_core ()->orb_params ()->thread_creation_flags ();" is comment out of the norify_service.cpp to make it running. before comment out, the error "cannot activate client threads" has been returned. the notify_service is running after this, but provide by default only synchronous messaging. If -dispatchingThreads 2 is set in the svc.conig to enable asynchronous messaging, the consumer admin cannot be obtained, the notify_service raises a system exception (BAD_PARAM). the same is true for the supplier admin, if I enable -sourceThreads 2. I use gcc 4.1 compiler. this promlem does not occur on windows 2000 with lower version of TAO.
Can you check the regression tests under TAO\orbsvcs\tests\Notify. These run fine in our daily regression suite. Having a reproducer will make it much easier to reproduce this, maybe this is a permission problem on your system?
(In reply to comment #1) > Can you check the regression tests under TAO\orbsvcs\tests\Notify. These run > fine in our daily regression suite. Having a reproducer will make it much > easier to reproduce this, maybe this is a permission problem on your system? > Sorry for my little delay, but I am very buisy that time and the pearl scripts for the tests do not work at all with the automatic build. After configurated multiple paths in the script, I was able to run the MT_Dispatching test for multiple threads per consumer. As I specified in the bug, the Notification Service has returned with a system exception. The console output is printed below. Hope that helps. tw@nbooktw:~/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching> ./run_test.pl Testing no threads .... Running Notification with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -IORoutput /home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/notify.ior -ORBSvcConf notify_nothreads.conf Loading the Cos Notification Service... Running 1 ORB threads Starting up the Notification Service... Registered with the naming service as: NotifyEventChannelFactory Activated Worker Thread to run the ORB @ priority:0 Running Supplier with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -c 10 -e 10 Running Consumer with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -c 2 -e 100 10 supplier(s) sending 10 events... +--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+--------------------+-------------------- Each Supplier sent 10 events. Waiting for stray events... Push Consumer disconnecting from supplier. Push Consumer disconnecting from supplier. Consumer done. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Push Supplier disconnecting from consumer. Testing multi-threaded dispatching .... Running Notification with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -IORoutput /home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/notify.ior -ORBSvcConf notify_mtdispatching.conf Using 2 threads for each ConsumerAdmin. Loading the Cos Notification Service... Running 1 ORB threads Starting up the Notification Service... Registered with the naming service as: NotifyEventChannelFactory Activated Worker Thread to run the ORB @ priority:0 Running Supplier with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -c 10 -e 10 -c 10 -e 10 Running Consumer with arguments: -ORBInitRef NameService=file:///home/tw/acetao/ACE_wrappers/TAO/orbsvcs/tests/Notify/MT_Dispatching/naming.ior -c 2 -e 100 -c 2 -e 100 (14318|3069277872) EXCEPTION, Error: system exception, ID 'IDL:omg.org/CORBA/BAD_PARAM:1.0' Unknown vendor minor code id (0), minor code = 0, completed = NO ERROR: Consumer returned 1
Steve, can OCI have a look at this one?
I think a have a patch for this BUG. In the source of the notify service, there is another thread_creation_flags() operation as described above or in BUG 1675. It is in the file orbsvcs/orbsvcs/Notify/ThreadPool_Task.cpp . After it has been comment out, the notify service example runns well with multiple dispatching threads and the communication becomes asynchronous.
Chad, would you please take a look at this bug as you have time?
Notes to myself: The value of the thread_creation_flags () is determined by TAO_ORB_Parameters::scope_policy() and TAO_ORB_Parameters::sched_policy() being or'ed together. The defaults are THR_SCOPE_PROCESS and THR_SCHED_DEFAULT respectively. Programatically this is configurable, but there is no way to set this via the service configurator or ORB initialization parameter. If these could be changed in this fashion, there would need to be no code changes to the notification service (and possibly other parts of TAO).
Chad, > The value of the thread_creation_flags () is determined by > TAO_ORB_Parameters::scope_policy() and TAO_ORB_Parameters::sched_policy() > being or'ed together. The defaults are THR_SCOPE_PROCESS and > THR_SCHED_DEFAULT respectively. > > Programatically this is configurable, but there is no way to set this via the > service configurator or ORB initialization parameter. If these could be > changed in this fashion, there would need to be no code changes to the > notification service (and possibly other parts of TAO). See the following ChangeLog entry (TAO/ChangeLogs/ChangeLog-06b): Thu Nov 9 15:42:32 UTC 2006 Chris Cleeland <cleeland_c@ociweb.com> * docs/ec_options.html: Add documentation for TPC and -ECDispatchingThreadFlags options. * orbsvcs/orbsvcs/Event/EC_Default_Factory.h: * orbsvcs/orbsvcs/Event/EC_Default_Factory.cpp: Added new option, -ECDispatchingThreadsFlags, that allows the user to pass in a list of thread creation flags and priority for dispatching threads. These can be used for either the MT dispatching strategy or the TPC dispatching strategy. Maybe it would be possible to re-use some of the code or ideas for this RTEC change in the Notification Service (or factor it out into a common util).
Created attachment 932 [details] Adds options to change the scheduling and scope parameters for the ORB. The ability to change the sched_policy and scope_policy were already there. I just added options to change them via the -ORB options to CORBA::ORB_init(). The RTCORBA loader has these same options via the service configurator.