First of all this blog entry is written for jgroups 2.5.1 and now jgroups.3-0-1-final is available and example is rewritten by me.
It is remommended to use new api. Because DistributedLock class is deprecated. Have a look at the new blog entry .
Let me jump in the source code again without any amateur explaination about Leader Election Problem.
Scenario : There will be three competitor in our cluster. First one will be the master (~leader) because there is no other one currently.
Second and Third One(s) won't have a chance to get "Distributed Lock". After a while our master will be killed by us with a big pleasure :)
Then we will see new MASTER(~leader of our cluster).You can see the message on snapshots below.
It is remommended to use new api. Because DistributedLock class is deprecated. Have a look at the new blog entry .
Let me jump in the source code again without any amateur explaination about Leader Election Problem.
Scenario : There will be three competitor in our cluster. First one will be the master (~leader) because there is no other one currently.
Second and Third One(s) won't have a chance to get "Distributed Lock". After a while our master will be killed by us with a big pleasure :)
Then we will see new MASTER(~leader of our cluster).You can see the message on snapshots below.
import org.jgroups.*; import org.jgroups.blocks.DistributedLockManager; import org.jgroups.blocks.VotingAdapter; import org.jgroups.blocks.NotificationBus; import org.jgroups.blocks.LockNotGrantedException; import java.io.Serializable; public class TheOne extends ReceiverAdapter { private JChannel channel; private volatile boolean becomeMaster; private DistributedLockManager lockManager; private VotingAdapter adapter; public static void main(String[] args) throws Exception { System.setProperty("jgroups.bind_addr", "10.34.34.137");//use your ip address TheOne master = new TheOne(); master.start(); } public void start() throws ChannelException { channel = new JChannel("udp.xml"); adapter = new VotingAdapter(channel); adapter.addMembershipListener(this); lockManager = new DistributedLockManager(adapter, "DistributedLockManager"); channel.connect("ClassPresidentCluster"); } public void viewAccepted(final View new_view) { new Thread() { public void run() { System.out.println("new view " + new_view); getLock(); } }.start(); } private void getLock() { if (becomeMaster) { System.out.println("-- STILL I am the ONE !!"); return; } try { System.out.println("looking for lock"); System.out.println(lockManager); System.out.println(adapter); lockManager.lock("writer", channel.getAddress(), 0); becomeMaster = true; System.out.println(" -- I AM THE ONE !!!"); } catch (ChannelException e) { e.printStackTrace(); } catch (LockNotGrantedException e) { System.out.println("no lock for me :("); } } }
1)First competitor comes to area a becomes a master very easily.
2)Second competitor comes to area but lock is owned by the first one.
3)Third competitor comes to area but lock is owned by the first one still.
4)After killing the master second one becomes a MASTER.
Hopefully someone is still watching this thread :) - How would you solve leader election in a split brain situation? (the cluster has split - then either "enough time" has passed so some node _wants_ to be the leader of the leaderless part, or some new node has been created in the leaderless part)?
ReplyDelete1)Try this http://www.jgroups.org/manual/html/user-advanced.html#d0e3462 Section: 5.6.3. The Split Brain syndrome and primary partitions
ReplyDelete2)And go there finally : http://old.nabble.com/JGroups-f2622.html
Bela Ban is there
ps : only one is watching this thread ;)