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 2015/12/04 00:49:22 UTC
Refactoring Event Receivers in Messaging Component
Hi Devs,
Started doing $subject. The Event Receiver model was designed when Stratos
cannot be run on a single JVM, and it was not properly re-factored once the
Stratos single JVM distribution came up. So, all the main components
(Stratos Manager, Cloud Controller, Autoscaler) has their own Message
Queues, Event Listeners, Processors and Processor Chains. However, the
Topology model is a common to all the components, therefore the we actually
have three sets of classes as mentioned above, updating the Topology. This
is unnecessary, the code is complex and hard to maintain.
This can be changed so that each JVM will have only a single set of Message
Queues, Event Listeners, Processors and Processor Chains of each event
type. All the other component who are interested in a particular event can
access the event receiver object and call addEventListener method to
register a listener to get notified on the relevant events.
The following are the main changes:
1. Make all *EventReceiver classes singleton; Stratos will have one
Event Receiver for main event categories (Topology, Tenant, Instance
Status, Instance Notifier, Initializer, Health Stat, Domain Mapping,
Cluster Status, Application and Signup) per JVM.
2. Remove the multiple EventReceivers in the components (ex:.
StratosManagerTopologyEventReceiver, AutoscalerHealthStatEventReceiver,
etc.). Instead of creating multiple queues, delegators, processors and
processor chains, they will now act like listeners for each processor.
3. Rename the component specific event receiver classes to reflect their
actual functionality.
WDYT?
--
Thanks and Regards,
Isuru H.
+94 716 358 048* <http://wso2.com/>*
Re: Refactoring Event Receivers in Messaging Component
Posted by Isuru Haththotuwa <is...@apache.org>.
This is now completed and pushed to stratos-4.1.x and master branch.
On Sat, Dec 5, 2015 at 9:36 PM, Imesh Gunaratne <im...@apache.org> wrote:
> +1 for the suggestion Isuru! This would improve the time it takes to
> handle locks and also would not print warning logs for already processed
> events.
>
> Thanks
>
> On Fri, Dec 4, 2015 at 5:19 AM, Isuru Haththotuwa <is...@apache.org>
> wrote:
>
>> Hi Devs,
>>
>> Started doing $subject. The Event Receiver model was designed when
>> Stratos cannot be run on a single JVM, and it was not properly re-factored
>> once the Stratos single JVM distribution came up. So, all the main
>> components (Stratos Manager, Cloud Controller, Autoscaler) has their own
>> Message Queues, Event Listeners, Processors and Processor Chains. However,
>> the Topology model is a common to all the components, therefore the we
>> actually have three sets of classes as mentioned above, updating the
>> Topology. This is unnecessary, the code is complex and hard to maintain.
>>
>> This can be changed so that each JVM will have only a single set of
>> Message Queues, Event Listeners, Processors and Processor Chains of each
>> event type. All the other component who are interested in a particular
>> event can access the event receiver object and call addEventListener method
>> to register a listener to get notified on the relevant events.
>>
>> The following are the main changes:
>>
>> 1. Make all *EventReceiver classes singleton; Stratos will have one
>> Event Receiver for main event categories (Topology, Tenant, Instance
>> Status, Instance Notifier, Initializer, Health Stat, Domain Mapping,
>> Cluster Status, Application and Signup) per JVM.
>> 2. Remove the multiple EventReceivers in the components (ex:.
>> StratosManagerTopologyEventReceiver, AutoscalerHealthStatEventReceiver,
>> etc.). Instead of creating multiple queues, delegators, processors and
>> processor chains, they will now act like listeners for each processor.
>> 3. Rename the component specific event receiver classes to reflect
>> their actual functionality.
>>
>> WDYT?
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
>
> --
> Imesh Gunaratne
>
> Senior Technical Lead, WSO2
> Committer & PMC Member, Apache Stratos
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
> * <http://wso2.com/>*
>
>
>
Re: Refactoring Event Receivers in Messaging Component
Posted by Imesh Gunaratne <im...@apache.org>.
+1 for the suggestion Isuru! This would improve the time it takes to handle
locks and also would not print warning logs for already processed events.
Thanks
On Fri, Dec 4, 2015 at 5:19 AM, Isuru Haththotuwa <is...@apache.org> wrote:
> Hi Devs,
>
> Started doing $subject. The Event Receiver model was designed when Stratos
> cannot be run on a single JVM, and it was not properly re-factored once the
> Stratos single JVM distribution came up. So, all the main components
> (Stratos Manager, Cloud Controller, Autoscaler) has their own Message
> Queues, Event Listeners, Processors and Processor Chains. However, the
> Topology model is a common to all the components, therefore the we actually
> have three sets of classes as mentioned above, updating the Topology. This
> is unnecessary, the code is complex and hard to maintain.
>
> This can be changed so that each JVM will have only a single set of
> Message Queues, Event Listeners, Processors and Processor Chains of each
> event type. All the other component who are interested in a particular
> event can access the event receiver object and call addEventListener method
> to register a listener to get notified on the relevant events.
>
> The following are the main changes:
>
> 1. Make all *EventReceiver classes singleton; Stratos will have one
> Event Receiver for main event categories (Topology, Tenant, Instance
> Status, Instance Notifier, Initializer, Health Stat, Domain Mapping,
> Cluster Status, Application and Signup) per JVM.
> 2. Remove the multiple EventReceivers in the components (ex:.
> StratosManagerTopologyEventReceiver, AutoscalerHealthStatEventReceiver,
> etc.). Instead of creating multiple queues, delegators, processors and
> processor chains, they will now act like listeners for each processor.
> 3. Rename the component specific event receiver classes to reflect
> their actual functionality.
>
> WDYT?
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>
--
Imesh Gunaratne
Senior Technical Lead, WSO2
Committer & PMC Member, Apache Stratos