Based on the Anjana's suggestions, to support different products having
different way of coordination.
My suggestion is as follows
//This has to be a *one time thing* I'm not sure how we should have API for
this!
//ID is Task or GroupID
//Algorithm-class can be a class or name registered in carbon TBD
void preformElection(ID, Algorithm-class);
//Register current node to do/join the Task denoted by the ID
void registerAsTaskWorker(ID);
//Check is the current node is the coordinator
boolean isCoordinator(ID);
//Get the coordinator for the ID.
NodeID getCoordinator(ID);
We also need a Listener for Coordinator
CoordinatorListener
void coordinatorChanged(ID,NodeID);
WDYT?
Suho
On Thu, Jan 16, 2014 at 8:32 PM, Anjana Fernando <[email protected]> wrote:
> Hi,
>
> On Thu, Jan 16, 2014 at 5:10 AM, Sriskandarajah Suhothayan
> <[email protected]>wrote:
>
>> We also need an election API,
>>
>> E.g for certain tasks only one/few node can be responsible and if that
>> node dies some one else need to take that task.
>>
>> Here user should be able to give the Task Key and should be able to get
>> to know whether he is responsible for the task.
>>
>> It is also impotent that the election logic is pluggable based on task
>>
>
> The task scenarios are similar to what we do in our scheduled tasks
> component. I'm not sure if that type of functionality should be included in
> this API, or did you mean, you need the election API to build on top of it?
> ..
>
> Also, another requirement we have is, creating groups within a cluster.
> That is, when we work on the cluster, sometimes we need a node a specific
> group/groups. And it each group will have it's own coordinator. So then,
> there wouldn't be a single coordinator for the full physical cluster. I
> know we can build this functionality on a higher layer than this API, but
> then, effectively the isCoordinator for the full cluster will not be used,
> and also, each component that uses similar group functionality will roll up
> their own implementation of this. So I'm thinking if we build in some
> robust group features to this API itself, it will be very convenient for it
> consumers.
>
> So what I suggest is like, while a member joins for the full cluster
> automatically, can we have another API method like, joinGroup(groupId),
> then later when we register a membership listener, we can give the groupId
> as an optional parameter to register a membership listener for a specific
> group. And as for the isCoordinator functionality, we can also overload
> that method to provide a gropuId, or else, in the membership listener
> itself, we can have an additional method like "coordinatorChanged(String
> memberId)" or else, maybe more suitable, "assumedCoordinatorRole()" or
> something like that to simply say, you just became the coordinator of this
> full cluster/group.
>
> Cheers,
> Anjana.
>
>
>>
>> Regards
>> Suho
>>
>>
>> On Thu, Jan 16, 2014 at 4:56 PM, Afkham Azeez <[email protected]> wrote:
>>
>>>
>>>
>>>
>>> On Thu, Jan 16, 2014 at 4:55 PM, Kishanthan Thangarajah <
>>> [email protected]> wrote:
>>>
>>>> Adding more.
>>>>
>>>> Since we will follow the whiteboard pattern for adding new
>>>> MembershipListener's, we don't need to have the methods (
>>>> *addMembershipListener, **addMembershipListener*) explicitly at API
>>>> level. Users will implement their MembershipListener's and register it as
>>>> an OSGi service. The clustering component will discover these and add it
>>>> the cluster impl.
>>>>
>>>>
>>> +1
>>>
>>>
>>>
>>>>
>>>> On Wed, Jan 15, 2014 at 3:03 PM, Afkham Azeez <[email protected]> wrote:
>>>>
>>>>> Anjana & Suho,
>>>>> Please review this & let us know whether these APIs address your
>>>>> requirements.
>>>>>
>>>>> Azeez
>>>>>
>>>>>
>>>>> On Wed, Jan 15, 2014 at 1:40 PM, Kishanthan Thangarajah <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> This thread is to discuss about $subject.
>>>>>>
>>>>>> Our current clustering API's contains stuffs that are mixture of both
>>>>>> user level and developer level API. We will have to separate out these
>>>>>> with
>>>>>> the clear definition.
>>>>>>
>>>>>> For clustering API (user level), we will have the following methods.
>>>>>> We can discuss clustering SPI's on a separate thread.
>>>>>>
>>>>>> * void sendMessage(ClusterMessage clusterMessage);*
>>>>>>
>>>>>> * void sendMessage(ClusterMessage clusterMessage,
>>>>>> List<ClusterMember> members);*
>>>>>>
>>>>>> * List<ClusterMember> getMembers();*
>>>>>>
>>>>>> * void addMembershipListener(MembershipListener
>>>>>> membershipListener);*
>>>>>>
>>>>>> * void removeMembershipListener(MembershipListener
>>>>>> membershipListener);*
>>>>>>
>>>>>> In here we also thought of having MembershipListener (A listener
>>>>>> which gets notified when changes occur in Membership) related API at user
>>>>>> level. This will be useful when user wants to get some event notification
>>>>>> when the current membership changes. Adding a new MembershipListener will
>>>>>> follow the white board pattern.
>>>>>>
>>>>>> The API for MembershipListener
>>>>>>
>>>>>> * void memberAdded(MembershipEvent event);*
>>>>>>
>>>>>> * void memberRemoved(MembershipEvent event);*
>>>>>>
>>>>>> MembershipEvent will be of two types (member added or removed).
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> Thanks,
>>>>>> Kishanthan.
>>>>>> --
>>>>>> *Kishanthan Thangarajah*
>>>>>> Senior Software Engineer,
>>>>>> Platform Technologies Team,
>>>>>> WSO2, Inc.
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> Mobile - +94773426635
>>>>>> Blog - *http://kishanthan.wordpress.com
>>>>>> <http://kishanthan.wordpress.com>*
>>>>>> Twitter - *http://twitter.com/kishanthan
>>>>>> <http://twitter.com/kishanthan>*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Afkham Azeez*
>>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>>> * <http://www.apache.org/>*
>>>>> *email: **[email protected]* <[email protected]>
>>>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>>>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>>>> *twitter:
>>>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>>>
>>>>> *Lean . Enterprise . Middleware*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> *Kishanthan Thangarajah*
>>>> Senior Software Engineer,
>>>> Platform Technologies Team,
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> Mobile - +94773426635
>>>> Blog - *http://kishanthan.wordpress.com
>>>> <http://kishanthan.wordpress.com>*
>>>> Twitter - *http://twitter.com/kishanthan
>>>> <http://twitter.com/kishanthan>*
>>>>
>>>
>>>
>>>
>>> --
>>> *Afkham Azeez*
>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> * <http://www.apache.org/>*
>>> *email: **[email protected]* <[email protected]>
>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>> *twitter:
>>> **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez>
>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>
>>> *Lean . Enterprise . Middleware*
>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *S. Suhothayan *
>> Associate Technical Lead,
>> *WSO2 Inc. *http://wso2.com
>> * <http://wso2.com/>*
>> lean . enterprise . middleware
>>
>>
>> *cell: (+94) 779 756 757 <%28%2B94%29%20779%20756%20757> | blog:
>> http://suhothayan.blogspot.com/ <http://suhothayan.blogspot.com/> twitter:
>> http://twitter.com/suhothayan <http://twitter.com/suhothayan> | linked-in:
>> http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
>>
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Anjana Fernando*
> Technical Lead
>
> WSO2 Inc. | http://wso2.com
> lean . enterprise . middleware
>
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
--
*S. Suhothayan*
Associate Technical Lead,
*WSO2 Inc. *http://wso2.com
* <http://wso2.com/>*
lean . enterprise . middleware
*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
<http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan
<http://twitter.com/suhothayan> | linked-in:
http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
