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

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

onStoreTimeout is called by poll thread, which causes a new local_var to be
implicitly created with a new queue (specific to poll thread, which isn't
supposed to have one).
To know the queue that should receive AnswerHasLock, reuse the one
registered to dispatcher to receive AnswerStoreObject.

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

Make it optional, to suit "ping" use, but check that it's always passed
except in that special case.

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

This fixes cases where a thread is expecting some answer from queue, and
a packet gets forgotten, as it would block until next expected packet
arrives (if there is no next packet, it will wait forever).

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

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

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

- Merge sys.exit()
- Remove exit message
- Move out of loop the code that should run once
- Add an XXX

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

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