Almost any use of packet was to retreive the msg_id of the request and pass it to answer().
In storage's replicator, critical TIDs are indexed with UUID instead of remote connection ID (full replicator review required).
In admin node, expected answers are still queued with the msg_id but it seems useless as no concurrent queries should happen.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1569 71dcc9de-d417-0410-9af5-da40c76e7ee4

The connection now store the last generated remote ID. If no msg_id is supplied to answer(), the last received ID will be used.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1568 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1567 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1566 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1565 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1564 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1563 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1562 71dcc9de-d417-0410-9af5-da40c76e7ee4

Hiding exceptions is *bad* .

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1561 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1560 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1559 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1558 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1557 71dcc9de-d417-0410-9af5-da40c76e7ee4

This condition is always true as the primary_node was found by UUID.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1556 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1555 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1554 71dcc9de-d417-0410-9af5-da40c76e7ee4

This fixes strange epoll results (yielding unknown file descriptors).
There is no explanation as of why it worked in 64bits until now.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1553 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1552 71dcc9de-d417-0410-9af5-da40c76e7ee4

Consequence of previous commit, to preserve code clarity.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1551 71dcc9de-d417-0410-9af5-da40c76e7ee4

This state was only internal to master node, and was not even
consistently handled in master (only the first election was done in that
state).
changeClusterState was never called with that state as parameter.
Finally, remove this state from protocol as it's not used any longer.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1550 71dcc9de-d417-0410-9af5-da40c76e7ee4

So that unknown nodes, to which no connection succeed for the current election, are dropped from election process.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1549 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1548 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1547 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1546 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1545 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1544 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1543 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1542 71dcc9de-d417-0410-9af5-da40c76e7ee4

- Nodes start in UNKNOWN state.
- Running and Unknown nodes are candidates during election.
- Set temporarily down if an established connection is lost.
- Keep in unknown state if a connection fails.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1541 71dcc9de-d417-0410-9af5-da40c76e7ee4

After the AnswerPrimary was received, the unconnected_master_node_set was filled with the primary address, causing a new connection at the next iteration in the _doElection method.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1540 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1539 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1538 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1537 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1536 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1535 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1534 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1533 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1532 71dcc9de-d417-0410-9af5-da40c76e7ee4

A single fd might be reported more than once per epoll call. This causes
the associated connection to be registered multiple times, which in turn
causes problems when the first connection registration gets emptied:
handling events of the second registration will raise an error when trying
to fetch a packet from an empty list.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1531 71dcc9de-d417-0410-9af5-da40c76e7ee4

git-svn-id: https://svn.erp5.org/repos/neo/trunk@1530 71dcc9de-d417-0410-9af5-da40c76e7ee4