About the potential use of twisted framework.

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

Since the last OID used (in a transaction) is synchronized with the storages,
it is no more required to restart a NEO cluster after an import. Remove the
related message.

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

- A storage is not operational while connecting to the primary master
- A storage is not ready until connected to a primary master, with an
operational partition table and fully initialized. The 'ready' attribute
must be initialized to False when PrimaryFailure or OperationFailure
exceptions are reaised to prevent acceptation of incoming clients (see
storage/handlers/identification.py that check app.ready value)

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

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

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

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

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

- The storages no more check the last OID during a store
- The storages inconditionnaly store the last OID notified by the master
- The master check during the if a greater oid was used by a client
- The master always notify the last OID when a pool is generated or if the
check above is True
- The master's transaction manager manager the last oid and oid generator

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

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

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

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

This fix an issue where some locks were not released on a storage because the
node list used to sent abort notifications was built with the content of
data_dict that don't keep informations about unresolved conflicts.

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

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

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

There are 2 objectives:
- Prevent randomly trying to connect to an unresponsive storage node, which
  impairs performances a lot. Note that this happens only when the master
  didn't notice the disconnection, so the node is still in running state in
  the node manager.
- Increase connection reuse, saving the cost of establishing a new
  connection and a slot in connection pool.
Randomisation should be kept to even out storage node use.

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

Deadlock occurs between connection establishment (which holds the pool
lock and waits for an answer on its thread queue) and epoll thread, which
tries to unregister the connection from pool (trying to take pool lock)
before notifying the queue.
Unregistering a connection from pool does not require taking the pool lock,
as it is just meant to prevent connections from being created in parallel.

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

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

A connection lost no more abort current transactions and clean the node
index (by calling abortFor). Do this job each time a transaction aborted
to avoid empty entries and memory leaks.

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

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

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

Bug reported by Gaël Le Mignot: in a sample case he encountered,
"description" was a unicode object, causing encoding failure in packet
construction.
Python "str" is used in ZODB FileStorage code (see format.py), so just do
the same.

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

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

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

ConnectorConnectionClosedException might get triggered when notifying a
node about transaction abortion, causing tpc_abort to fail eating pending
answers and clearing local_var.
Swallow all exceptions (various network problems translating to various
exceptions).

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

This avoids sending multiple abort messages for each storage node (one per
partition it is assigned to).

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

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

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

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

When a delayed store is processed, don't take the lock if the transaction
is no more registered (may have been aborted due to a timeout with the
delayed store).
Change the TransactionManager API: add register() that must be called before
any storeObject/storeTransaction operation.

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

This requires the live debugger to be enabled. Only master, storage and
client side handle this signal.

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

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

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

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

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

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

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

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

If the last storage node gets disconnected, an operation failure will
occur, so there is no risk of sending AnswerTransactionFinished to client
if some object was not stored.

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

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

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