Closed lightem90 closed 9 years ago
As tou can see here (output4.txt) it doesn't answer with pre-write-ack to 1 and 2, even if we enter in parseInput.. have to investigate why. Line 94: Received pre-write from node #3 Line 95: I'm in handleInit: request->pre-write from->3 Line 96: I'm in parseInput: request->pre-write from->3 Line 97: Sending: pre-write-ack to /10.1.1.4:33879 Line 99: Received pre-write from node #1 Line 100: I'm in handleInit: request->pre-write from->1 Line 101: I'm in parseInput: request->pre-write from->1 Line 104: Received pre-write from node #2 Line 105: I'm in handleInit: request->pre-write from->2 Line 106: I'm in parseInput: request->pre-write from->2 Line 119: Received pre-write from node #3 Line 120: I'm in handleInit: request->pre-write from->3 Line 121: I'm in parseInput: request->pre-write from->3 Line 122: Sending: pre-write-ack to /10.1.1.4:33879
Some more output from today tests: outten1.txt outten2.txt outten3.txt outten4.txt outten9.txt outten10.txt
This time node 1 did some writes but eventually got stuck, none 2 was stuck since first op, counter algorithm seems to work properly, even with lower thresholds (not shown here).
a very fast analysis shows that at a certain point 1 and 2 try to write a view with a smaller tag than the one owned by the node. this results to it not sending the ack. must check what the algorithm says about this case, also, fixing tag printing in next commit
While testing the increment algorith on 10 nodes network and 3 writers this happend: node 3 kept writing while 1 and 2 were stuck to the first write (query phase was completed but they where both waiting for all the response to pre-write). node 3 kept writing and updating the label correctly. I'm attaching output files of node 1-4 an 9-10
output4.txt output3.txt output2.txt output1.txt output10.txt output9.txt