I know that when the candidater receive a heartbeat with higher Term, it will convert to follower of the new leader. but there is a case the Raft paper do not talk about.
When the candidater receive a voteRequest with Higher Term, what should the candidater do?
If a Candidate receives a RequestVote RPC with a term higher than its own, it should convert to a Follower and grant its vote for that term to the node requesting it (assuming the log matching property is satisfied and there are no other RequestVote RPCs with an equal or higher term).
Related
I want to understand following scenario:
3 node cluster ( n1, n2, n3 )
Assume n1 is the leader
Client send operation/request to n1
For some reason during the operation i.e. ( appendentry, commitEntry ... ) leader changes to n2
But n1 has successfully written to its log
Should this be considered as failure of operation/request ? or It should return "Leader Change"
This is an indeterminate result because we don't know at the time if the value will be committed or not. That is, the new leader may decide to keep or overwrite the value; we just do not have the information to know.
In some systems that I have maintained the lower-level system (the consensus layer) gives two success results for each request. It first returns Accepted when the leader puts it into its log and then Committed when the value is sufficiently replicated.
The Accepted result means that the value may be committed later, but it may not.
The layers that wrap the consensus layers can be a bit smarter about the return value to the client. They have a broader view of the system and may retry the requests and/or query the new leader about the value. That way the system-as-a-whole can have the customary single return value.
I have a Azure Logic app that will pull all messages of a queue once a day. In the Loop action, I can extract the amount and convert to float to extract the value, however, I am not sure how to create a running total of all of the messages in the queue. To be clear, so if there are 10 messages in the queue, and each message has an amount of $1, the running total at the end should be $10. Does anyone know how to do this ?
I have tried using the Math function add(variables('TotalPayments'), variables('PaymentAmount'))
TotalPayments - Running Total
PaymentAmount - current Payment extracted from the current Message.
Found a solution to this, What I used was to implement a increment variable and assigned the value from the current message to this variable. There could be an easier way of doing this, however, It achieves the desired result, and I spent far too much time on it. Microsoft may have meant some other way, but isn't forthcoming in the documentation (that I could find, would be gladly told otherwise). Like I indicated above, I was using the Math function add which seemed logical to me to use but that didn't work.
I have 2 commands
1) DebitCommand (Debit Credit card)
2) CreditCommand (Credit to Account)
From our use case perspective Debit and Credit combination is one atomic operation which are connected to 2 different systems (Rest call).
When CreditCommand circuit breaker is short circuited it doesn't make sense to debit or else we need to refund the money back. which actually increases an unnecessary call. Is there any way which hystrix solves this.
My thoughts:
Approach 1: Merge DebitCommand and CreditCommand into a single credit command
Approach 2: In DebitCommand execute call some how get the status of the circuit of CreditCommand and allow only when Circuit Breaker is opened or Half Opened or revert back.
If any one who has experienced with this use case, could you please help how you have solved this use case
Approach 2 Querying circuit state as a basis for whether to place a call, ( in pseudo-code: if (circuit is healthy) { Place call through circuit } ) is not a sensible way to proceed, even if available. In a highly-concurrent/multi-threaded environment, the circuit state could change between evaluating the if condition and placing the inner call. So this approach offers no guarantee that the second call will succeed.
I'm learning MIT 6.824 class and I have a question about paxos. When proposer send a prepare to acceptor, acceptor will return a prepare_ok with n and v which highest accept see. I wonder why acceptor need to return n and v?
In a nutshell, the acceptor must return v because if the value was already committed then the new proposer needs to know what it is. There is no global "is_committed" flag, so the proposer gathers all these values and their associated rounds from at least a majority of the acceptors. The proposer then sends the value with the highest round to all the acceptors.
As you can see, a proposer always finishes what another proposer has started when it receives a value from an acceptor. This is a little bit similar to a lot of wait-free algorithms.
I have an App Engine Python App where players post their answers to questions and a team of judges vote them as right or wrong. Votes are cast by justices using this model:
class vote(ndb.Model):
judge = ndb.KeyProperty(justice)
value = ndb.BooleanProperty()
timestamp = ndb.DateTimeProperty(auto_now_add = True)
question = ndb.KeyProperty(game_has_question_has_player)
And questions have this structure:
class game_has_question_has_player(ndb.Model):
match = ndb.KeyProperty(game)
challenge = ndb.KeyProperty(questionList)
gamer = ndb.KeyProperty(player)
answer = ndb.StringProperty()
passed = ndb.BooleanProperty()
As soon as the number of positive or negative votes accounts for 1/2 +1 of the judges the question is deemed as passed or failed. This can happen before all the judges have voted and is key to the App dealing the rest of the challenges to go on with the game.
My problem has to do with that moment. How can I know reliably when a challenge/question has just been passed? To summarize where I am stuck, this are the options I am able to see:
The voting method queries previous votes and decides (taking into account the vote being cast) wether to update the "passed" field in "game_has_question_has_player". The problem here is that queries to count previous votes can give a wrong answer due to other votes being simultaneously cast by the rest of the judges and other counts being performed also simultaneously.
I change the 'question' model to add a counter for the votes. I see a contention problem there as judges are notified simultaneously of the challenges to vote and can therefore vote very close in time to each other. I can use transactions, but I am not clear about it's limitations in production (I am in development server now). In a certain game there can easily be 10 judges, but if the games account for the thousands votes scale * =~10 * number of questions * number of players.
I postpone the recount with a task queue. If every vote does the same: Are we not in the same case as the first point, only postponed ?
I have read about sharding counters, but I don't see them fit here; The votes are correctly cast, is just the "event" of passing the test which seems tricky to me.
Thanks very much for any insight or ideas.
Transactions should work here and will not be a problem in the future. They only "lock" the touched Entity Groups and won't avoid you to scale.
Your third point should work too, if you delay the launch of you taskqueues enough (I would say 3 to 5s). The datastore should be up to date during this check.
But nothing avoids you to try this 2 solutions together, just to be "sure".