Shreedhar and Mohamed,
Thank you both for your prompt replies. We can certainly do without this
feature since we have some alternative workarounds. But there were 2 use
cases that prompted my original question:
- We have a number of components within every single member of cluster,
and hence if we needed to temporarily shutdown one of the components, we
wanted to make sure that this node is not leader for the duration of
recycling the faulted component.
- We also thought that there might be situation were we might want to a
member to relinquish its leadership due to resource constraints (until
this could be corrected).
On a separate note, are you using the invitation algorithm for the
leader election?
Thanks,
Alireza
-----Original Message-----
From: Shreedhar.Ganapathy_at_Sun.COM [mailto:Shreedhar.Ganapathy_at_Sun.COM]
Sent: Wednesday, February 13, 2008 11:51 AM
To: users_at_shoal.dev.java.net
Subject: Re: [Shoal-Users] Ceasing Leadership
I understand the obvious benefit but not all group comm libs provide the
facility to have a deterministic master chosen by the application.
The implementation on the lines you describe is already implemented by
Sheetal a few weeks ago, to help manage the situation where the master
is one of the core cluster members and that cluster is being shutdown by
a Spectator member who happens to be an admin application controlling
the lifecycle of the cluster.
This helped GlassFish use cases where planned shutdown notifications
were, as a result of this facility, more correctly disseminated.
I am interested in hearing from Shoal users like Alireza what other
specific use cases a facility of this sort helps. This will help us
differentiate Shoal's provider features from other implementations.
hth
Shreedhar
Mohamed Abdelaziz wrote:
> I can see the benefit of such feature.
>
> Alireza, it should be fairly straight forward to implement (1 day
> implementation, 1 day QA). It would entail an addition of a master
> node protocol message (to indicate a takeover action between two
> nodes, then followed by an assertion by the new master), and exposing
> the API's from the provider level up to the GMS level. Submit an
> issue along with a patch, we'll gladly consider the new feature.
>
>
> Mohamed
>
>
> Shreedhar Ganapathy wrote:
>> In a sense this exists as a forcible takeover API thereby allowing an
>> existing leader to relinquish its leader role.
>> I would be very interested in your use case though as it will help
>> make our documentation on intended uses for such a thing more clear.
>>
>> Sent from my phone
>>
>> On Feb 13, 2008, at 7:14 AM, Shreedhar Ganapathy
>> <Shreedhar.Ganapathy_at_Sun.COM <mailto:Shreedhar.Ganapathy_at_Sun.COM>>
>> wrote:
>>
>>> That's not something we found a need for. So it does not exist
>>> today. Is there use case where this would be useful? Thanks
>>> Shreedhar
>>>
>>> Sent from my phone
>>>
>>> On Feb 13, 2008, at 7:08 AM, Alireza Farhoush <alireza_at_tibco.com
>>> <mailto:alireza_at_tibco.com>> wrote:
>>>
>>>> Can a member relinquish its role as a leader without leaving its
>>>> group (assuming that there are more that one member of course)?
>>>>
>>>> Thanks,
>>>>
>>>> Alireza
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
> For additional commands, e-mail: users-help_at_shoal.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_shoal.dev.java.net
For additional commands, e-mail: users-help_at_shoal.dev.java.net