the incrementing "ports_per_node" got changed to 2? H2O.java still checks for 3 ports per node, so have to increment by 3. weird h2o didn't complain more on multi-jvm. don't know when it was wrong/right
fixed RPC class printing in Timeline.
Merge branch 'master' of github.com:0xdata/h2o
tweaking test
test tweaks
use PROPOSAL_MAX_SENT on the outgoing side, to guarantee all proposals from a node have a unique proposal_num, regardless of delays in processing incoming proposals into larger PROPOSAL_MAX. invariant: all proposal_nums from a node are unique and monotonically increasing, and also always > any incoming proposal num seen (i.e. PROPOSAL_MAX). this requires PROPOSAL_MAX on the input side, and PROPOSAL_MAX_SENT on the outgoing side, with both affecting proposal_num used.
add 1 sec delay between h2o starts when remote hosts are used. seems to be more reliable.
junit.py was failing because it assumes h2o uses two sequential ports per jvm
H2O.java error message implies 3. I guess we use 2 so changing back. I was confused today.
I'm voting this way because it makes sense to me and useful tests pass that used to fail.
If the accepted votes say the cloud is a certain way (a "view") , and some node is in it, and then if there is a heartbeat from that guy, and he doesn't think he's in that view, the leader (or someone) should send out another Accepted message.

Currently it's conditioned more than I think it should be, currently. That leads to cases where a bad situation doesn't get fixed. (i.e. static non-fully-built cloud). The "static bad" is when the full cloud isn't formed, but no new proposals are coming from the leader. (I checked that the heartbeats seemed to be there.

This change is part of not allowing bad states to be static, and recovering from illegal states.

Basically, you don't want a secondary kind of decision making to be happening...i.e. that a node can "modify" the view, or ignore a node because he doesn't have the rght view yet. (but you got a heartbeat from him)

if there is future debate in what the view should be, the leader and proposal_num behaviors will sort it out, and a new view will get voted on.

Remember it's all about "one view". No matter where you're at, it's about having "one view" in the end. (and you keep on doing stuff until there's "one view" amongst all who heartbeat each other. Mixing hw diagnostics in the middle muddies the thinking (i.e. a half-broken node)
updated to step jvms by 2 ports not 3
everyone incs by 2 ports per jvm now
increase timeout
get rid of some unnecessary checking/waiting, to go faster
make them all have a polling interval of 2secs (retryDelaySecs)
reduce this to 8 jvms per host
don't have to inc ports between clouds any more? reuse ok?
Inside doAccepted, this code looks like it has a typo, using "_state" instead of "state" the passed in parameter. I highlighted it in red. My thinking is we want the members the leader sent (the param), not the local _state buffer, for members:
If it's wrong, can undo tomorrow. Testing on single and two machine setups at home is as good as things were yestereday.

    HashSet<H2ONode> members = new HashSet(Arrays.asList(_state._members)); <---going to change to "state._members"
Merge remote-tracking branch 'upstream/master'