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