Further if you want, you can build your own object model based on the
events you listen.


On Sat, May 3, 2014 at 2:11 AM, Nirmal Fernando <[email protected]>wrote:

>
>
>
> On Sat, May 3, 2014 at 2:01 AM, Akila Ravihansa Perera <[email protected]
> > wrote:
>
>> Thanks Nirmal, that was very helpful.
>>
>> But what about a member deactivation event as a result of scale-down?
>>
>
> It is the same as activation. Autoscaler decides to scale-down.... and
> once member is ready to be shutdown, cloud-controller would terminate the
> member and send out a member terminated event.
>
>>
>> Just to clarify, if we are going to implement topology event extension
>> points for Cartridge Agent, then it should also process the complete
>> topology and complete tenant events only once according to this
>> pattern?
>>
>>
> So, the best practice would be, to listen for the complete* events in
> order to initialize and then identify the events that you would want to
> listen and act only upon those events, thereafter.
>
>>
>>
>> On Sat, May 3, 2014 at 1:37 AM, Nirmal Fernando <[email protected]>
>> wrote:
>> > Hi Akila,
>> >
>> > Complete* events are there only for the system to withstand a restart.
>> So,
>> > each of the server would initially wait till it receives the complete*
>> event
>> > and adjust it state to the current system state and then from that point
>> > onwards, each server would react on the events that occurs.
>> >
>> > If I take your sample, in the case of member activation during a server
>> life
>> > time, servers would listen to MemberActivatedEvents and process.
>> >
>> >
>> > On Sat, May 3, 2014 at 1:09 AM, Akila Ravihansa Perera <
>> [email protected]>
>> > wrote:
>> >>
>> >> Hi Imesh,
>> >>
>> >> I noticed that you have made a commit [1] that will make the LB to
>> >> process complete topology and complete tenant events only once. But
>> >> could you explain the reason for it to be like that? Shouldn't the LB
>> >> be aware of topology changes that might occur in the future? It might
>> >> not be aware of members getting active/inactive dynamically.
>> >>
>> >> I'm just trying to understand the workflow here, would really
>> >> appreciate if anyone can provide some background information on this.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >> [1]
>> >>
>> https://github.com/apache/incubator-stratos/commit/783197eaba9edd70212ca70b39679502274fd230
>> >>
>> >>
>> >> --
>> >> Akila Ravihansa Perera
>> >> Software Engineer
>> >> WSO2 Inc.
>> >> http://wso2.com
>> >>
>> >> Phone: +94 77 64 154 38
>> >> Blog: http://ravihansa3000.blogspot.com
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards,
>> > Nirmal
>> >
>> > Nirmal Fernando.
>> > PPMC Member & Committer of Apache Stratos,
>> > Senior Software Engineer, WSO2 Inc.
>> >
>> > Blog: http://nirmalfdo.blogspot.com/
>>
>>
>>
>> --
>> Akila Ravihansa Perera
>> Software Engineer
>> WSO2 Inc.
>> http://wso2.com
>>
>> Phone: +94 77 64 154 38
>> Blog: http://ravihansa3000.blogspot.com
>>
>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>



-- 
Best Regards,
Nirmal

Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.

Blog: http://nirmalfdo.blogspot.com/

Reply via email to