Thanks all. Furthermore, I plan to do the following refactoring:
- An abstraction and MQTT based implementation of a message receiver which can handle the re-connection logic that we are currently missing. - Abstraction for MessageDelegators - Abstraction for local event receiver On Sat, Nov 15, 2014 at 1:14 PM, Udara Liyanage <[email protected]> wrote: > Hi, > > While going through the code I tried to understand what the threads are > doing, > > StratosManagerTopologyEventReceiver > creates TopologyEventReceiver and add event listerns - Not an iterative > process. See the run method just keep on sleeping while terminates become > true > > TopologyEventReceiver > creates TopologyEventMessageDelegator and start as a thread > creates TopicSubscriber and set TopologyEventMessageListener(which is not > a thread) as message listener > This too not a iterative thread. > > TopologyEventMessageDelegator > takes messages from the queue and handles it to messsage processor chain > This is an iterative process > > TopicSubscriber > Subscribe to topic and and joins with TopicHealthChecker thread. > This is a kind of iterative process since it needs to reconnect when > desconnected. > > So TopologyEventMessageDelegator and TopicSubscriber are the only > iterative processes which must need to be run as a runnable. If I > understood correctly other threads are kept running just > to terminate running threads when the component is deactivated for some > reason such as stooping the server. They have the following in common in > run method > > while (!terminated) { > sleep() > } > > If we use an executor service, we don't need them to keep on running. > > On Fri, Nov 14, 2014 at 11:53 PM, Imesh Gunaratne <[email protected]> > wrote: > >> Yes, better to do this improvement in all the message broker topic >> listeners. >> >> On Fri, Nov 14, 2014 at 1:36 PM, Chamila De Alwis <[email protected]> >> wrote: >> >>> Hi, >>> >>> Furthermore, it seems this is a pattern followed all over Stratos, where >>> each component has a {component}{topic}EventReceiver runnable. Shouldn't we >>> consider them too? If we do, then this will be a major test task. >>> >>> >>> Regards, >>> Chamila de Alwis >>> Software Engineer | WSO2 | +94772207163 >>> Blog: code.chamiladealwis.com >>> >>> >>> >>> On Fri, Nov 14, 2014 at 1:17 PM, Imesh Gunaratne <[email protected]> >>> wrote: >>> >>>> Yes better to do this improvement Isuru. >>>> >>>> On Fri, Nov 14, 2014 at 12:20 PM, Udara Liyanage <[email protected]> >>>> wrote: >>>> >>>>> Hi Isuru, >>>>> >>>>> +1 pooling for threads is an unnecessary overhead. >>>>> >>>>> On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa <[email protected] >>>>> > wrote: >>>>> >>>>>> Hi Devs, >>>>>> >>>>>> This thread is to discuss $subject. >>>>>> >>>>>> Let me explain the current flow, taking Topology event listener in >>>>>> Stratos Manager as an example. >>>>>> >>>>>> 1. SM Topology event receiver is started in a separate thread >>>>>> 2. In the SM Topology event receiver thread, we start another >>>>>> thread with an instance of messaging's TopologyEventReceiver class. >>>>>> 3. Again in the TopologyEventReceiver thread, we create couple of >>>>>> more threads for the Topology event message delegator and topic >>>>>> subscriber. >>>>>> >>>>>> IMHO there is no need to create all these threads. AFAIU, what we >>>>>> need are three threads which will: >>>>>> >>>>>> 1. Listen to the events >>>>>> 2. Handles delegation >>>>>> 3. Updates the local topology models >>>>>> >>>>>> Also, we can use java ExecutorServices handle graceful >>>>>> starting/termination of threads. Currently, we are doing sleeping/looping >>>>>> mechanism to keep the threads alive, which can be replaced with >>>>>> ExecutorService. >>>>>> >>>>>> WDYT? >>>>>> -- >>>>>> Thanks and Regards, >>>>>> >>>>>> Isuru H. >>>>>> +94 716 358 048* <http://wso2.com/>* >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Udara Liyanage >>>>> Software Engineer >>>>> WSO2, Inc.: http://wso2.com >>>>> lean. enterprise. middleware >>>>> >>>>> web: http://udaraliyanage.wordpress.com >>>>> phone: +94 71 443 6897 >>>>> >>>> >>>> >>>> >>>> -- >>>> Imesh Gunaratne >>>> >>>> Technical Lead, WSO2 >>>> Committer & PMC Member, Apache Stratos >>>> >>> >>> >> >> >> -- >> Imesh Gunaratne >> >> Technical Lead, WSO2 >> Committer & PMC Member, Apache Stratos >> > > > > -- > > Udara Liyanage > Software Engineer > WSO2, Inc.: http://wso2.com > lean. enterprise. middleware > > web: http://udaraliyanage.wordpress.com > phone: +94 71 443 6897 > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048* <http://wso2.com/>* > > > * <http://wso2.com/>* > > >
