You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stratos.apache.org by Isuru Haththotuwa <is...@apache.org> on 2014/11/14 07:33:04 UTC
[Messaging] Refactoring the Event Listeners
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/>*
Re: [Messaging] Refactoring the Event Listeners
Posted by Chamila De Alwis <ch...@wso2.com>.
Hi,
It seems the purpose of the StratosManagerTopologyEventReceiver is to
provide methods to add event listeners. We can have this functionality in a
non-runnable class too. However from the TopologyEventReceiver onwards I
think it's essential to keep the threading model because of the nature of
processing chain.
The TopicSubscriber will be listening to the events and invoking the
TopologyEventMessageListener which puts the event in to a queue. The
TopologyEventMessageDelegator starts the processing chain on each of the
message from the queue. If this is to be chained, a broader approach will
have to be taken on the messaging component too, IMHO.
Regards,
Chamila de Alwis
Software Engineer | WSO2 | +94772207163
Blog: code.chamiladealwis.com
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 <is...@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
>
Re: [Messaging] Refactoring the Event Listeners
Posted by Gayan Gunarathne <ga...@wso2.com>.
Hi Akila,
On Wed, Jul 22, 2015 at 12:32 AM, Akila Ravihansa Perera <ravihansa@wso2.com
> wrote:
> 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
>
We can add the executor service to that InstanceNotifierEventReceiver
listener too.
>
> Thanks.
>
> On Sun, Nov 16, 2014 at 10:10 PM, Lahiru Sandaruwan <la...@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 <is...@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 <ch...@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 <
>>>>>>>> isuruh@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: lahirus@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
>
--
Gayan Gunarathne
Technical Lead, WSO2 Inc. (http://wso2.com)
Committer & PMC Member, Apache Stratos
email : gayang@wso2.com | mobile : +94 766819985
Re: [Messaging] Refactoring the Event Listeners
Posted by Akila Ravihansa Perera <ra...@wso2.com>.
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 <la...@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 <is...@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 <ch...@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 <
>>>>>>> isuruh@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: lahirus@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
Re: [Messaging] Refactoring the Event Listeners
Posted by Lahiru Sandaruwan <la...@wso2.com>.
+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 <is...@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 <ch...@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 <
>>>>>> isuruh@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: lahirus@wso2.com blog: http://lahiruwrites.blogspot.com/
linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
Re: [Messaging] Refactoring the Event Listeners
Posted by Isuru Haththotuwa <is...@apache.org>.
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 <ch...@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 <isuruh@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/>*
>
>
>
Re: [Messaging] Refactoring the Event Listeners
Posted by Udara Liyanage <ud...@wso2.com>.
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 <ch...@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 <is...@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
Re: [Messaging] Refactoring the Event Listeners
Posted by Imesh Gunaratne <im...@apache.org>.
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 <ch...@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 <is...@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
Re: [Messaging] Refactoring the Event Listeners
Posted by Chamila De Alwis <ch...@wso2.com>.
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 <is...@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
>
Re: [Messaging] Refactoring the Event Listeners
Posted by Imesh Gunaratne <im...@apache.org>.
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 <is...@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
Re: [Messaging] Refactoring the Event Listeners
Posted by Udara Liyanage <ud...@wso2.com>.
Hi Isuru,
+1 pooling for threads is an unnecessary overhead.
On Fri, Nov 14, 2014 at 12:03 PM, Isuru Haththotuwa <is...@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