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

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?.

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.

Thanks & Regards,
Tharindu


Tharindu Munasinghe.
Undergraduate, Department of Computer Science and Engineering
University of Moratuwa.
Contact no. +94770460887



On Wed, May 2, 2018 at 9:49 PM, Questions/problems related to using JGroups
<[email protected]> wrote:

>
>> 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.
>>
>
> After all the help I've received here, am responding to try to repay the
> favor. Hopefully I'm not misleading you on anything.
>
> Yes, you can have a shared state across the cluster. In our app, we have a
> state that includes a bunch of things about the cluster. It's a small Java
> object that implements org.jgroups.util.Streamable. In the base class for
> our main code, we override ReceiverAdapter getState and setState to do the
> appropriate things. When a new node joins the cluster, getState is called
> on the coordinator automatically and the result is used for setState on the
> new node. JGroups does that for you with the STATE_TRANSFER protocol.
>
> Whenever something happens in our cluster that would change this state,
> the coordinator sends a message to all the other nodes saying "reload the
> shared state." Each node (besides the coordinator) then calls
> JChannel#getState in a new thread to have the new state set on that node.
>
> For your case where you want to designate a "master" node separate from
> the coordinator, this might work for you.
>
> Look for 'state' here:
> http://www.jgroups.org/manual/html/user-channel.html
>
> 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
>
>

------------------------------------------------------------------------------
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