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

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

And clear queued event.

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

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

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

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

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

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

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

The signal is often received during epoll_wait call, and python code later
checks the value of libc's errno. That value might get tainted by
sighandler, causing errors to be detected after the call (epoll_wait would
return -1 as the call was interrupted by the signal).

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

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

Disabled by default, as it allows code injection in NEO processes to
anyone with the ability to send signals to them and either write access to
NEO product or its controlling TTY.

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

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

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

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

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

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

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

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

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

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

If it is still identified, the node would still be referenced in node
manager although having been asked for removal.

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

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

- Don't trash a node to recreate it right after (it was the case when a
  node was known by address only).
- Check node type consistency between:
  - parameters and node found
  - node known by type and node known by UUID
- Log actions before doing them, consistently
- Log found node in addition to loop variables
- Don't call remove when an unknown node is notified as down, and add a
  log for this case

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

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

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

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

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

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

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

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

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

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

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

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

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

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