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

This check was always false in the case of a client.
Move the 'node is None' condition in the potential scope.

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

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

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

Keep lock around _initNodeConnection() in connection pool to avoid concurrent
connections to the same storage node.

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

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

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

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

- Drop it from app
- Don't split packets as 10000 entries is beyond NEO expectations.
- Iterate over used nodes only (instead of filtering)

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

- Remove connector option (not available in master, storage or admin)
- Use '-c' to specify the cluster name

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

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

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

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

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

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

- Unify log methods among classes.
- Define log() on event manager

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

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

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

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

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

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

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

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

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

SendPartitionTable packet was sent between Ask and Answer PartitionTable
packets, as notifications. In this case, the only purpose of the 'Answer'
was to check that the partition table was filled. The 'Ask' allowed also
to request a part of the partitions but was not used and redundant with
AskPartitionList for neoctl.

This commit include the following work:
- The partition table is always send in one packet.
- The full partition table is always requested with AskPartitionTable
- The full partition table is notified with SendPartitionTable
- Client node process the answer in the bootstrap handler.
- Admin can receive answer *and* notifications for the partition table.
- Move the log calls to the pt.py module
- Add pt.getRowList() to factorise the code.
- Build partition table packets out of the loop when possible
- Always load inconditionnaly the partition table in generic pt.py
-

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

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

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

This fix an issue where a client was notified down, dropped from node
manager then detected as disconnected: the node was not found.

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

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

Store deadlocks might happen when the order in which storage nodes receive
object data (and hence, grant write lock for those objects) is not
consistent among clients. So when a store timeouts, it might be because
another transaction got the store lock on this storage and object, while
it might wait for locks we got on other storage nodes or objects.
In doubt, report a conflict to abort current transaction in hope for the
other transaction to succeed.

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

As we don't (and must not, otherwise it would deadlock) take a write lock
on a storage node when detecting a conflict, it is possible that multiple
conflicts get successively reported for a single object in a single
transaction. To solve this, client must tolerate multiple conflict for a
single object. The last resolved conflict being sent to all storage nodes,
transaction data will be consistent at tpc_finish.

- conflict_serial_dict and resolved_conflict_serial_dict become
  multivalued (sets instead of scalar)
- each resolution only resolve conflict with highest serial if greater
  than previous resolutions for the same object
  NOTE: this assumes that ("r" being conflict resolution method, "Tn"
  being the TID on which object is based, and "Cn" being a conflict with
  transaction n) when r(T0, C1) generates T1 but triggers C2,
    r(T0, C1) + r(T1, C2) == r(T0, C2)

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

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

Such function is provided when message is queued for send when an answer
is expected, and is called when the answer is not arrived after expiration
of the timeout delay. Depending on the return value of this callback, the
timeout is ignored (True) or passed through (False).

Also, move code to refresh next timeout value to a separate function, for
reusability.

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

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

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

This allows always checking whether a storage accepted the object for a
conflicting serial value, so do it.

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

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

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

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

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