#Socket server not receiving message

13 messages · Page 1 of 1 (latest)

full forge
#

GitHub: https://github.com/JadoreThompson/kv-store.git
Branch: feature/raft

I'm implementing raft consensus algorithm and encountering a logical error during testing.

Within my current implement, each node uses the RaftManager class. The RaftManager is a co-ordinator class holding a connection to the current controller, a broker server of it's own and connections to peer broker servers. When an election is triggered, the node looking to be elected will trigger the state of the manager to be set to candidate. Each broker connection will see this state update and send a vote request to the broker. The broker will send a response to the vote request back to the corresponding client. The client will then provide the response to the manager. The manager will then increment vote count if the node was granted a vote and if voteCount >= majority then the state is changed from CANDIDATE to CONTROLLER. This state change is again viewed by the broker clients who will send a leader elected message to the broker. The broker is then to close the client connection since it's no longer a broker and provide the message to the manager which will close the connection to the current controller and connect to the new controller.

The issue I'm facing is that only the broker which provided the last vote to bring voteCouont to majority is the one receiving the leader elected message although each client is successfully sending the message. Meaning all other nodes aren't being updated.

GitHub

Contribute to JadoreThompson/kv-store development by creating an account on GitHub.

lapis hearthBOT
#

This post has been reserved for your question.

Hey @full forge! Please use /close or the Close Post button above when your problem is solved. Please remember to follow the help guidelines. This post will be automatically marked as dormant after 720 minutes of inactivity.

TIP: Narrow down your issue to simple and precise questions to maximize the chance that others will reply in here.

zenith apex
#

You could maybe point out, what are the involved classes since currently the repo has like 30 classes and I would have to look into all of them to see how they interact and what they do.

#

For debugging I would first look into the place where the "leader elected" message is generated and sent.
Is it really sent to all clients?
Does the controller even know about all clients at that point?
Are the connections still open or have they been closed for some reason?
If the messages are sent, are they received successfully?
Are the message handlers setup correctly?
Is this process asynchronous or are they expecting this message as direct answer to a previous message? Etc.

full forge
full forge
# zenith apex For debugging I would first look into the place where the "leader elected" messa...
  1. The leader elected message is sent from client to server.
  2. The controller is indeed aware of all clients it holds.
    3 & 4. The client which receives the vote request response which causes voteCount >= majority will successfully have it's message read from the server RaftBrokerServerHandler.
  3. Yes message handlers configured correctly.
  4. Yes it's asynchronous. This message is only sent if a node receives enough votes to be elected leader
#

Test method:

#
mvn test -Dtest=LeaderElectionTest#completeElectionCycle_fromInitiationToCompletion_with3Nodes
zenith apex
#

For JUnit tests another thing which could also be involved is that when the main test method is terminated, JUnit will also kill all spawned threads of other components.

lapis hearthBOT
#

💤 Post marked as dormant

This post has been inactive for over 720 minutes, thus, it has been archived.
If your question was not answered yet, feel free to re-open this post or create a new one.
In case your post is not getting any attention, you can try to use /help ping.
Warning: abusing this will result in moderative actions taken against you.

full forge
#

I solved it. Within the processData methods I was calling compact which I originally thought would prevent re-reads of bytes but didn't. So I replaced it with a call to clear and then rewind to eradicate the mark if present and reset position to 0