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 <isu...@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/>*
>
>
>

Reply via email to