Re: [jgroups-users] Ability to set the coordinator programaticaly and the ability to maintain a shared state
Questions/problems related to using JGroups <[email protected]> Tue, 8 May 2018 07:01:55 +0530
| Newsgroups | gmane.comp.java.javagroups.general |
|---|---|
| Message-ID | <mailman.5625.1525743164.977.javagroups-users@lists.sourceforge.net> |
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 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. 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. 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. 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]> 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/manual >> 4/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]>> 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> >> >> >> [1] >> https://github.com/belaban/JGroups/wiki/Changing-the-coordin >> ator-of-a-cluster >> <https://github.com/belaban/JGroups/wiki/Changing-the-coordi >> nator-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]> >> 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]> >> 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, 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] > 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