Re: [jgroups-users] Ability to set the coordinator programaticaly and the ability to maintain a shared state

On 08/05/18 03:31, Questions/problems related to using JGroups wrote:
> Hi Bela,
> 
> Thanks for your confirmation on this. So far to achieve this goal I have 
> tried following approach,
> 1) Created 2 channels (designated masters only channel and  a public 
> channel where everybody can connect)
> 2) Both channels can have separate jGroups level coordinators.
> 3) JGroup coordinator of the public channel does not essentially become 
> the application level Master.
> 4) Application level master is a shared state variable in the public 
> channel. (Anybody joins new can fetch this state via state transfer)
> 5) The application will be blocked until this shared state is available 
> within the public channel. (No client can proceed until it gets this 
> variable or currently known master is unavailable within the channel)
> 6) For simplicity, I took the current jGroups level coordinator of the 
> designated masters only channel, as my application level master.
> 7) Whenever the designated masters only channel's coordinator gets 
> changed, I'll send a message to the public channel to instruct the 
> master change event.

This may work, but IMO may be a bit too complex.

Also, how does your application behave under network partitions?

> This solution actually worked so far but had some underminastic 
> behaviors in merge views. I've tried primary partition approach to 
> manage the application level master state.

Note that the primary partition approach only approximates what a 
consensus-based protocol (such a Raft) can do. E.g. you can end up with 
multiple coordinators...

> But sometimes it deviates from my original assumption (coordinator of 
> jGroups master's channel always becoming the application level master). 
> In fact, during the state merging it actually picks one of the 
> designated masters always but not necessarily the coordinator of the 
> jGroups master's only channel.

Again, this can be customized by using a MembershipChangePolicy, which 
can also be applied to MergeViews, not just Views.

> I would be grateful if you could review this design and give small 
> feedback on feasibility/risk of doing this in a production setup. 
> Especially if you could suggest a reliable method to maintain the 
> application level master state consistently, it would be highly 
> appreciated.

I don't like to have 2 channels. It is IMO better to have 1 channel only 
and elect the application master, e.g. via view changes, or a special 
election protocol.
If you need to take partitions into account, then perhaps a system such 
as jgroups-raft fits the bill better.

> Thanks & Regards,
> Tharindu,
> 
> 
> Tharindu Munasinghe.
> Undergraduate, Department of Computer Science and Engineering
> University of Moratuwa.
> Contact no. +94770460887
> 
> 
> 
> On Mon, May 7, 2018 at 8:39 PM, Questions/problems related to using 
> JGroups <[email protected] 
> <mailto:[email protected]>> wrote:
> 
> 
> 
>     On 05/05/18 6:40 AM, Questions/problems related to using JGroups wrote:
> 
>         Hi all,
> 
>         Thank a lot for the answer. The reference
>         http://www.jgroups.org/manual4/index.html#MembershipChangePolicy
>         <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy>
>         <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy>>
>         seems to be promising. It has most of the requirements I wanted
>         to implement. In fact, my solution requires some of the nodes
>         are prevented from becoming the coordinator. In other words, out
>         of all the nodes, there are set of nodes which are designated
>         clients (they shouldn't become the master at any point because
>         they don't have the data layer). Rest of them can become masters
>         and there is a priority order for leadership. So as I understood
>         the MembershipChangePolicy allows me to specify the priority of
>         designated masters. But I am still wondering whether I can
>         prevent some of the nodes becoming the coordinator while they
>         get all the view changes and messages.
> 
> 
>     Well, you can *prioritize* certain members to become coordinators.
>     However, if there are only members left in the cluster who are not
>     supposed to become coordinators, then one of them will inevitably
>     become coordinator. You cannot have a cluster _without_ a coord; one
>     of the members has to be coord.
> 
>         Any help on this would be highly appreciated.
> 
> 
>         Thanks & Regards!
>         Tharindu
> 
> 
>         Tharindu Munasinghe.
>         Undergraduate, Department of Computer Science and Engineering
>         University of Moratuwa.
>         Contact no. +94770460887
> 
> 
> 
>         On Thu, May 3, 2018 at 12:56 PM, Questions/problems related to
>         using JGroups <[email protected]
>         <mailto:[email protected]>
>         <mailto:[email protected]
>         <mailto:[email protected]>>> wrote:
> 
> 
> 
>              On 29/04/18 10:45, Questions/problems related to using
>         JGroups wrote:
> 
>                  Hi all,
> 
>                  I am new to jGroups but I found this is an elegant
>         library for
>                  cluster management. I have 2 main requirements for one
>         of my
>                  projects.
> 
>                  First, is it possible to programmatically change the
>                  coordinator of the jGroups cluster?. I am using the jgroups
>                  coordinator as the application level master (for some
>                  domain-specific application) of the server's cluster.
>         But for
>                  a given server to become the application level master there
>                  are some application level criteria to be fulfilled. So in
>                  case of the jGroups coordinator cannot fulfill those
>                  requirements I want to change the coordinator of the
>                  jGroups programmatically. I found [1] for this purpose,
>         but I
>                  wanted to understand whether this is a reliable method
>         or is
>                  there any side effects of doing this. If there is a
>                  recommanded approach, please share that with me.
> 
> 
>              [1] certainly works, but is a kludge. I recommend
>         implementing a
>              membership plugin [2], which determines the order of
>         members in a
>              view. You can thus control who the coordinator is/becomes.
>         [1] can
>              be used to change the coordinator when no view is getting
>              installed, e.g. triggered by the application.
> 
> 
>                  The second question is about the ability to maintain a
>         shared
>                  state. Is it possible to maintain a state which is visible
>                  across the cluster?. So the changes are synchronized
>         among the
>                  available members and visible to all members without
>                  explicit message passing about the changes.
> 
> 
>              Yes, use state transfer, check the manual for details. Note
>         that
>              the state is the same across *all* cluster members, which
>         may lead
>              to heap exhaustion if you have a large state and/or many
>         members.
> 
> 
>              [2]
>         http://www.jgroups.org/manual4/index.html#MembershipChangePolicy
>         <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy>
>             
>         <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy <http://www.jgroups.org/manual4/index.html#MembershipChangePolicy>>
> 
> 
>                  [1]
>         https://github.com/belaban/JGroups/wiki/Changing-the-coordinator-of-a-cluster
>         <https://github.com/belaban/JGroups/wiki/Changing-the-coordinator-of-a-cluster>
>                 
>         <https://github.com/belaban/JGroups/wiki/Changing-the-coordinator-of-a-cluster
>         <https://github.com/belaban/JGroups/wiki/Changing-the-coordinator-of-a-cluster>>
> 
>                  Thanks & Regards!
>                  Tharindu,
> 
>                  Tharindu Munasinghe.
>                  Undergraduate, Department of Computer Science and
>         Engineering
>                  University of Moratuwa.
>                  Contact no. +94770460887
> 
> 
> 
> 
>                 
>         ------------------------------------------------------------------------------
>                  Check out the vibrant tech community on one of the
>         world's most
>                  engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
>                  _______________________________________________
>                  javagroups-users mailing list
>         [email protected]
>         <mailto:[email protected]>
>                  <mailto:[email protected]
>         <mailto:[email protected]>>
>         https://lists.sourceforge.net/lists/listinfo/javagroups-users
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users>
>                 
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users>>
> 
> 
>              --     Bela Ban | http://www.jgroups.org
> 
> 
>             
>         ------------------------------------------------------------------------------
>              Check out the vibrant tech community on one of the world's most
>              engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>              _______________________________________________
>              javagroups-users mailing list
>         [email protected]
>         <mailto:[email protected]>
>              <mailto:[email protected]
>         <mailto:[email protected]>>
>         https://lists.sourceforge.net/lists/listinfo/javagroups-users
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users>
>             
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users>>
> 
> 
> 
> 
>         ------------------------------------------------------------------------------
>         Check out the vibrant tech community on one of the world's most
>         engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
>         _______________________________________________
>         javagroups-users mailing list
>         [email protected]
>         <mailto:[email protected]>
>         https://lists.sourceforge.net/lists/listinfo/javagroups-users
>         <https://lists.sourceforge.net/lists/listinfo/javagroups-users>
> 
> 
>     -- 
>     Bela Ban, JGroups lead (http://www.jgroups.org)
> 
> 
> 
>     ------------------------------------------------------------------------------
>     Check out the vibrant tech community on one of the world's most
>     engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>     _______________________________________________
>     javagroups-users mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/javagroups-users
>     <https://lists.sourceforge.net/lists/listinfo/javagroups-users>
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> javagroups-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/javagroups-users
> 

-- 
Bela Ban | http://www.jgroups.org


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
javagroups-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/javagroups-users