Hi, While going through the changes that were made to event listeners, I noticed that InstanceNotifierEventReceiver [1] does not have an executor service while other event listeners do. Was this done on purpose?
[1] https://github.com/apache/stratos/blob/master/components/org.apache.stratos.messaging/src/main/java/org/apache/stratos/messaging/message/receiver/instance/notifier/InstanceNotifierEventReceiver.java Thanks. On Sun, Nov 16, 2014 at 10:10 PM, Lahiru Sandaruwan <lahi...@wso2.com> wrote: > +1 for the improvement Isuru. Probably we should do a hangout on these > implementation. > > On Sun, Nov 16, 2014 at 8:06 PM, Isuru Haththotuwa <isu...@apache.org> > wrote: > >> 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 <ud...@wso2.com> 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 <im...@apache.org> >>> 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 <chami...@wso2.com> >>>> 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 <im...@apache.org> >>>>> wrote: >>>>> >>>>>> Yes better to do this improvement Isuru. >>>>>> >>>>>> On Fri, Nov 14, 2014 at 12:20 PM, Udara Liyanage <ud...@wso2.com> >>>>>> wrote: >>>>>> >>>>>>> Hi Isuru, >>>>>>> >>>>>>> +1 pooling for threads is an unnecessary overhead. >>>>>>> >>>>>>> On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa < >>>>>>> isu...@apache.org> 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/>* >>> >>> >>> > > > -- > -- > Lahiru Sandaruwan > Committer and PMC member, Apache Stratos, > Senior Software Engineer, > WSO2 Inc., http://wso2.com > lean.enterprise.middleware > > email: lahi...@wso2.com blog: http://lahiruwrites.blogspot.com/ > linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146 > > -- Akila Ravihansa Perera Software Engineer, WSO2 Blog: http://ravihansa3000.blogspot.com
