This simplifies code (and I should have done it this way from the
beginning).
Keep the lock check wrapper in MT subclass as it should have been added in
r2025 anyway.

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

When a handler sends a request, always queue the response for handling
within the same handler, possibly delaying further a pending handler
switch.
This is for example required to properly complete identification between
master nodes, as the connecting master node might exit election phase
before receiving peer's AnswerPrimary when peer happens to be the primary.

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

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

If a first packet is sent and its answer received in time, then a second
packet is sent after more than PING_DELAY seconds, a ping will be emitted
right after that second packet, because _ping_time was still set.
This change resets it when there is no pending requests.

Also, as required to have a consistent view of _handlers, check that lock
is properly held in the MT variant of the class.

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

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

If this check fails, hard and soft checks will produce different results.

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

conn.getUUID() will always return None on a not-identified-yet node, so
the test was always false when a  was given.
Also, test app.primary_master_node for None instead of primary_uuid, as
the case where an unknown primary UUID is received must be handled.

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

There is no need to make a special case in waitStoreResponses if it becomes
equivalent to just calling waitResponses.

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

This prevents from having an endless wait on "get" if the last connection
from which we were expecting answers got interrupted.
Note that this method will not raise any error related to this.

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

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

Also, only check if connector is opened when needed, and use new "isClosed"
method on connection.

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

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

Those events are not purged at disconnection, ignore them here.

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

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

"was_connected" actually meant "was_not_connected". To avoid using a
negation in variable name, fix its use and values it's set to.

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

Such node might have died between connection establishment and answering
identification message, possibly causing ECONNRESET.

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

Cleanup actions are only appropriate if such exception happens in receive/
send, so it should not be applied to other possible sources of exceptions.

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

Any exception triggered by low-level code should cause a log and
connection closure before being propagated.

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

- dump() values
- include oid

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

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

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

Fixes the following scenario (committing an object):
2 storage nodes: S1 and S2
1 replicas
- store in S1 (1)
- store in S2 (2)
- S1 answers (1) with a conflict
- client resolves the conflict, and sends to S1 (3) and S2 (4)
- S1 answers (3) with ok
- S2 answers (2) with a conflict

Old code raises because object store counter was not 0 on an object for
which a conflict was reported.
New code ignores answers notifying of a conflict if given serial is the
already-resolved conflict.
Split & extend existing tests.

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

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

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

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

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

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

There are 2 distinct kinds of timeout events:
- an unresponsive node
  This is a connection-level timeout.
  This is handled by the Timeout class, triggering pings and monitoring
  incoming data to decide when remote node is considered dead.
- a "too long" processing from an otherwise responsive node
  This is a per-request timeout.
  This is handled by the HandlerSwitcher class, triggering only
  disconnections when an answer takes too long to arrive (historical
  behaviour, not so useful when exchanging with a single-threaded peer).

Previous implementation mixed both, and had shortcomings (ping would
timeout almost immediately, it was not possible to tell which message
caused a timeout).

Update tests.

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

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

This code appeared obscure upon second read, so I document it.

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

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

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

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

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

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

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

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

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

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

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