Let me explain:
I am making a network routing protocol analyze function
I get line for NODE 1 saying
2->4 4->4 5->4 6->6
Meaning to get to 2 go to 4, to get to 4 go to 4, to go to 5 go to 4...
I also hove "god view" of the topology
And now for the Question :) :
How should i calculate the sync % of a node?
1) goodChoices/allNeededPaths (if both 0 then sync=1)
2) goodChoices/allmychoices * badOrMissingChoices/allNeededPaths
3) what is your idea
Problems that need to think about
If god view is NONE-CONNECTED but in my NODE topology i see 4->4 5->4 what % should i right?
Related
I have 3 xbee. I have already config xbee 1 and xbee 2 become coordinator and end-device by using XCTU software and all value tha I configure is in the table below.
enter image description here
Now, i want to configure the remain xbee to become end-device and it can send and receive data from coordinator but I dont know the value DH DL. Can anybody help me with this?
Consider five nodes(S1,S2,S3,S4,S5) getting key/value data. And the following steps happened
S3 becomes leader and client write a key equal 2 to cluster
S3 append entry to S1,S2,S4,S5, then S1,S2,S4,S5 accept it and write entry to itself log（as shown in the picture 1）
S3 received majority response(from S1,S2,S4,S5), S3 commit entity that key equal 2, and send write succeed message to client, and then send commit message to S1,S2,S4,S5
S2,S4,S5 received commit message and commit entry success, but S1 crashed. just like in picture 2, S1 will have an uncommitted entry.
Now, S1 restart and become a leader with an uncommitted entry that key equal 2(as shown in the picture 3)
After above steps, client query an entry(key equal 2, just wrote succeed). But now S1 is leader and key equal 2 entry is uncommitted. So, client will can't find entry that itself wrote a moment ago. So, where I made a mistake? please help me
(picture 1)
(picture 2)
(picture 3)
I have found the solution at Diego Ongaro paper more detailed version In Search of an Understandable Consensus Algorithm(Extended Version). In section 8(Client interaction), I found the answer,
Raft handles this by having each leader commit a blank no-op entry into the log at the start of its
term. After this, In question S1 will commit log index equal 1 entry by commit a blank no-op entry.
Im trying to implement queuing system using redis. So lets say we have this list:
> LPUSH listTickets 1 2 3 4 5 6 7 8 9
and as mobile app user someone was assigned number 4, and another user number 6. Now I want to display to them how many tickets are in front of them ( also to calculate the waiting estimated time). Now this may seem easy,
> LPOP listTicket
"4"
then we broadcast the result (the current ticket number to be called), then on mobile app everyone will subtract it from their own ticket number. for example my current ticket is 6 so 6-4=2 That way every user know how many tickets are ahead
However once you want to add feature to let the user delete their ticket or pushing it to the end of the queue, things get complicated. After deleting for example
> LRANGE listTicket 0 -1
1) "2"
2) "4"
3) "6"
4) "7"
5) "8"
when we LPOP listTicket we will get number 2 and the mobile app with ticket 6 will calculate 6-2 and get 4 which is the wrong calculation.
Do you have any algorithm in mind? Is getting the index of every ticket in the list every time someone delete their ticket an expensive process to calculate? Should I just send all tickets in the queue and let the users calculate their own position?
I want the system to be scale-able. So can the redis-node server handle total of 50 thousands (over different queues or lists) connected mobile apps getting their ranking in the queue they subscribed their ticket to.
I thought about using ZRANK but how will this load the server?
I can't see the difference between two parameters for the recovery phase of the gateway module.
In the documentation :
The gateway.recover_after_nodes setting (which accepts a number) controls after how many (...) eligible nodes (...) recovery will start.
The gateway.expected_nodes allows to set how many (...) eligible nodes are expected to be in the cluster, and once met, (...) recovery starts
From what I understand, these two settings trigger the recovery phase once the number of node is equal to the value set.
Why using one over the other?
And what is the point of using both of them?
For example :
gateway:
recover_after_nodes: 3
expected_nodes: 5
In this case, what is the purpose of expected_nodes? recovery will be triggered as soon as there will be 3 nodes. There must be another reason to use it.
I hope my question is clear enough.
Thanks in advance!
When using recovery_after_nodes, recover_after_data_nodes or recovery_after_master_nodes, once all set conditions are met the cluster will then start waiting recover_after_time before starting recovery:
The gateway.recover_after_time setting (which accepts a time value)
sets the time to wait till recovery happens once all
gateway.recover_after...nodes conditions are met.
When using expected_nodes, expected_data_nodes or expected_master nodes, recovery will start once all conditions are met - the cluster will not wait. In addition, it will also default recovery_after_time to 5 min.
In your test case:
gateway:
recover_after_nodes: 3
expected_nodes: 5
Once you hit 3 nodes a countdown clock starts and the cluster will then recovery in either 5 minutes (the default) or if you hit 5 nodes. Basically it allows you to set a minimum threshold (recovery_after_nodes), with a timeout (recovery_after_time) to wait for a desired state (expected_nodes). You will either recovery recovery_after_time after recovery_after_nodes is hit, or when expected_nodes is hit (no additional waiting) - whichever comes first.
from the public document, there are misunderstandings in this threads.
http://www.elastic.co/guide/en/elasticsearch/reference/1.x/modules-gateway.html
gateway:
recover_after_time: 5m
expected_nodes: 2
In an expected 2 nodes cluster will cause recovery to start 5 minutes
after the first node is up, but once there are 2 nodes in the cluster,
recovery will begin immediately (without waiting).
so, the timer defined by recover_after_time will start already after a first node is up. not start after finding nodes defined in recover_after_nodes
I have following problem with tracking of Magento purchase on Google Analytics (custom theme, different from default checkout process).
My goal settings are following: http://db.tt/W30D0CnL, where step 3 equals to /checkout/onepage/opc-review-placeOrderClicked
As you can see from funnel visualization ( http://db.tt/moluI29d ) after step 2 (Checkout Start) there are a lot of exits toward /checkout/onepage/opc-review-placeOrderClicked which is setted as step 3, but step 3 reporting always 0.
Is there something that I'm missing here?
I've found the problem. Apparently second point (/checkout/onepage) was fired even on the third step.
When I changed it to regex match (/checkout/onepage$) everything started to work.