1. 02 Apr, 2021 8 commits
  2. 22 Mar, 2021 1 commit
  3. 04 Mar, 2021 2 commits
  4. 15 Jan, 2021 2 commits
    • Julien Muchembled's avatar
      ssl: don't care whether EOF is ragged or not · d98205d0
      Julien Muchembled authored
      The purpose of suppress_ragged_eofs=False was to micro-optimize the
      normal case: when there's no EOF.
      
      But commit 061cd5d8 showed that this
      option only turns ragged EOF into an exception. It may be easier for
      alternate NEO implementations to close the SSL connection properly. Or
      the performance benefit was not worth the risk to freeze a NEO process.
      d98205d0
    • Kirill Smelkov's avatar
      ssl: Don't ignore non-ragged EOF · 061cd5d8
      Kirill Smelkov authored
      Testing NEO/go client wrt NEO/py server revealed a bug in NEO/py SSL
      handling: proper non-ragged EOF from a peer is ignored, and so leads to
      hang in infinite loop inside _SSL.receive with read_buf memory growing
      indefinitely. Details are below:
      
      NEO/py wraps raw sockets with
      
      	ssl.wrap_socket(suppress_ragged_eofs=False)
      
      which instructs SSL layer to convert unexpected EOF when receiving a TLS
      record into SSLEOFError exception. However when remote peer properly
      closes its side of the connection, socket.read() still returns b'' to
      report non-ragged regular EOF:
      
      https://github.com/python/cpython/blob/v2.7.18/Lib/ssl.py#L630-L650
      
      The code was handling SSLEOFError but not b'' return from socket recv.
      Thus after NEO/go client was disconnecting and properly closing its side
      of the connection, the code started to loop indefinitely in _SSL.receive
      under `while 1` with  b'' returned by self.socket.recv() appended to
      read_buf again and again.
      
      -> Fix it by detecting non-ragged EOF as well and, similarly to how
      SSLEOFError is handled, converting them into self._error('recv', None).
      
      See merge request !17
      061cd5d8
  5. 11 Jan, 2021 4 commits
  6. 02 Oct, 2020 1 commit
    • Julien Muchembled's avatar
      Fix handling of -m/--masters arg · fa63d856
      Julien Muchembled authored
      For the master, the purpose of -m/--masters is to specify addresses
      of other master nodes, since its own address is already known via
      -b/--bind. Therefore, an empty value for -m/--masters is valid.
      The user remains free to repeat the -b value in -m.
      
      More generally, a node may choose to only specify master addresses
      via -D/--dynamic-master-list, so the check that at least one master
      address is specified is moved where the NodeManager is expected to be
      initialized.
      fa63d856
  7. 29 Sep, 2020 1 commit
  8. 25 Sep, 2020 4 commits
    • Julien Muchembled's avatar
    • Julien Muchembled's avatar
      New algorithm for deadlock avoidance · 5e7f34d2
      Julien Muchembled authored
      The time complexity of previous one was too bad. With several tens of
      concurrent transactions, we saw commits take minutes to complete and
      the whole application looked frozen.
      
      This new algorithm is much simpler. Instead of asking the oldest
      transaction to somewhat restart (we used the "rebase" term because
      the concept was similar to what git-rebase does), the storage gives
      it priority and the newest is asked to relock (this request is ignored
      if vote already happened, which means there was actually no deadlock).
      
      testLocklessWriteDuringConflictResolution was initially more complex
      because Transaction.written (client) ignored KeyError (which is not the
      case anymore since commit 8ef1ddba).
      5e7f34d2
    • Julien Muchembled's avatar
      qa: deindent code · d98b576c
      Julien Muchembled authored
      d98b576c
    • Julien Muchembled's avatar
      Update comments · dbf128b7
      Julien Muchembled authored
      dbf128b7
  9. 10 Sep, 2020 3 commits
  10. 04 Sep, 2020 1 commit
  11. 21 Aug, 2020 1 commit
  12. 25 Jun, 2020 1 commit
  13. 24 Jun, 2020 1 commit
  14. 12 Jun, 2020 1 commit
    • Julien Muchembled's avatar
      qa: skip broken ZODB test · f4cb59d2
      Julien Muchembled authored
      ======================================================================
      FAIL: check_tid_ordering_w_commit (neo.tests.zodb.testBasic.BasicTests)
      ----------------------------------------------------------------------
      Traceback (most recent call last):
        File "ZODB/tests/BasicStorage.py", line 397, in check_tid_ordering_w_commit
          self.assertEqual(results.pop('lastTransaction'), tids[1])
        File "neo/tests/__init__.py", line 301, in assertEqual
          return super(NeoTestBase, self).assertEqual(first, second, msg=msg)
      failureException: '\x03\xd8\x85H\xbffp\xbb' != '\x03\xd8\x85H\xbfs\x0b\xdd'
      f4cb59d2
  15. 11 Jun, 2020 1 commit
  16. 29 May, 2020 3 commits
  17. 18 May, 2020 1 commit
    • Julien Muchembled's avatar
      admin: fix monitoring timer after 2 identical consecutive checks · c611c48f
      Julien Muchembled authored
      This fixes the bug that with only email notification, monitoring
      stopped checking whether backup clusters are lagging after status is
      unchanged since the last check (about lagging, what is compared is
      the set of lagging backups). Until another event wakes up monitoring.
      
      The code is also simplified in that there's no need for the moment to
      have a different timeout between the normal case and a smtp failure.
      c611c48f
  18. 20 Mar, 2020 1 commit
  19. 16 Mar, 2020 2 commits
  20. 14 Feb, 2020 1 commit
    • Julien Muchembled's avatar
      master: fix tpc_finish possibly trying to kill too many nodes after client-storage failures · 82eea0cd
      Julien Muchembled authored
      When concurrent transactions fail with different storages (e.g. only network
      issues between C1-S2 and C2-S1), in such a way that each transaction can be
      committed but not both (or the cluster would be non-operational), and if the
      first transaction is aborted (between tpc_vote and tpc_finish), then the second
      wrongly failed with INCOMPLETE_TRANSACTION.
      
      And if both transactions could be committed (e.g. more than 1 replica),
      some nodes would be disconnected for nothing.
      82eea0cd