This allows to setup an almost fully functional cluster without additional
processes. Threads are scheduled so that they never run simultaneously,
eliminating most random.
There's still much improvement possible like controlled randomization,
or easier debugging when switching from one thread to another.

As mock objects are not usable in such tests, an API should be implemented to
trace/count any method call we'd like to check.

This fixes test_notifyNodeInformation_checkUnregisterStorage

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

- Previous implementation was not able to import transactions with many small
  objects, the client for faster to send a store request than to process its
  answer. If X is the difference of time for these 2 operations, the maximum
  number of objects a transaction could contain was CRITICAL_TIMEOUT / X.
  And HasLock feature can't act as a workaround because it is not working yet.
- Change API of 'on_timeout', which currently only used by HasLock.
- Stop pinging when we wait for an answer. This wastes resources and would
  never recover any bad state.
- Make client connections send pings when they are idle instead.
  This implements keep-alive feature for high availability.
  Start with an non-configurable period of 60 seconds.
- Move processing of ping/pong to handlers.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

This fixes a potential bug triggered by a storage disconnecting while this
loop would be running, expecting answers from that storage: this would
prevent this loop from ever exiting.

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

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

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

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

Maybe we could implement our own daemon system someday, but it's not high
priority enough to even be in the TODO list.

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

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

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

This fixes problems in multi-database setups (ie. ZODB and other
databases).
For example, imagine a transaction stores an object in ZODB and its
identifier in a relational database.
Then, another process connected to the same databases and polling the
relational database find the new entry, and tried to load the object from
ZODB.
If the second node didn't process invalidation sent by initial transaction
when it starts its transaction, second client would not be able to see that
object, which should not happen (inter-database inconsistency).

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

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

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

About the potential use of twisted framework.

git-svn-id: https://svn.erp5.org/repos/neo/trunk@2187 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@2116 71dcc9de-d417-0410-9af5-da40c76e7ee4

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

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

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

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

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

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

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

This is not fixed, IdleEvent is not associated to the packet that create it.

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

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