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]> Sat, 5 May 2018 17:24:00 -0400
| Newsgroups | gmane.comp.java.javagroups.general |
|---|---|
| Message-ID | <mailman.4441.1525555489.27734.javagroups-users@lists.sourceforge.net> |
On Sat, May 5, 2018 at 1:35 AM, Questions/problems related to using JGroups <[email protected]> wrote: > Hi all, > > Thank very much @Bobby for your valuable answer. Your answer actually > helps me to understand the usage of state transfer clearly. > > Just wanted to clarify a small thing. Did you mean that there is an > inbuilt message saying "reload the shared state" in the library itself > (similar to what happen when there is view change, the views get > automatically pushed to all the members) or did you propose a method to > fetch the latest state from the coordinator once the coordinator notifies > the clients?. > That last one. There actually might be something I don't know about, but when the coordinator sees that something has changed it notifies everyone. It sends out a specific string (or an enum, I forget) with Dispatcher#castMessage. All the nodes implement handle(Message message) and, when they see that, they call JChannel#getState. The getState() call is done in a separate thread so it doesn't block the handle() call. > In an abstract manner, a view is also kind of shared state which is > visible to all the member and any changes to the views are notified to all > members. I am wondering whether this could be applied to any application > level shared state. Basically other than client explicitly pulling from the > state from the coordinator is it possible for the coordinator to push the > changes to the state internally which invoke a callback similar to > viewAccepted() at client's end? or else is it possible to inject some > application level state to the view which would automatically address my > problem. > I *think* info about each node could be incorporated into info it already sends in the view (like with a custom Address implementation), but in my case there's info about the cluster in general that's unrelated to the individual nodes, so we pass a separate object around. Cheers, Bobby ------------------------------------------------------------------------------ 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