1. 12 Jun, 2017 6 commits
  2. 12 May, 2017 5 commits
  3. 11 May, 2017 1 commit
  4. 10 May, 2017 2 commits
  5. 04 May, 2017 1 commit
  6. 02 May, 2017 1 commit
    • Julien Muchembled's avatar
      master: fix identification of unknown masters · fbcf9c50
      Julien Muchembled authored
      This fixes the following crash:
      
        Traceback (most recent call last):
          ...
          File "neo/master/handlers/identification.py", line 94, in requestIdentification
            uuid = app.getNewUUID(uuid, address, node_type)
          File "neo/master/app.py", line 449, in getNewUUID
            assert uuid != self.uuid
        AssertionError
      fbcf9c50
  7. 28 Apr, 2017 3 commits
    • Julien Muchembled's avatar
      Better logging of connector errors · 29e8323c
      Julien Muchembled authored
      29e8323c
    • Julien Muchembled's avatar
    • Julien Muchembled's avatar
      client: fix possible data corruption after conflict resolutions with replicas · 46c36465
      Julien Muchembled authored
      This really fixes the bug described in
      commit 40bac312,
      which could probably be reverted. It only reduced the probability of failure.
      
      What happened is that the second conflict on 'a' for t3 what first reported by
      an answer to first store with:
      - a base serial at which a=0
      - a conflict serial at which a=7
      However, the cached data is not 8 anymore but 12, since a second store already
      occurred after the first conflict (reported by the other storage node).
      
      When this conflict was resolved before receiving the conflict for second store,
      it gave:
      
        resolve(old=0, saved=7, new=12) -> 19
      
      instead of:
      
        resolve(old=4, saved=7, new=12) -> 15
      
      (if we still had the data of the first store, we could also do
        resolve(old=0, saved=7, new=8)
       but that would be inefficient from a memory point of view)
      
      The bug was difficult to reproduce. testNotifyReplicated had to be run many
      many times before that race conditions trigger it. The test was changed to
      enforce some of them, and the above scenario now happens almost always.
      46c36465
  8. 27 Apr, 2017 7 commits
  9. 25 Apr, 2017 4 commits
  10. 24 Apr, 2017 6 commits
  11. 19 Apr, 2017 2 commits
  12. 18 Apr, 2017 2 commits
    • Julien Muchembled's avatar
      Fix sorting of delayed events · 40bac312
      Julien Muchembled authored
      The initial intention was to rely on stable sorting when several events have
      the same key. For this to happen, sorting must not continue the comparison with
      the second item of events.
      
      This could lead to data corruption (conflict resolution with wrong base):
      
        FAIL: testNotifyReplicated (neo.tests.threaded.test.Test)
        ----------------------------------------------------------------------
        Traceback (most recent call last):
          File "neo/tests/threaded/__init__.py", line 1093, in wrapper
            return wrapped(self, cluster, *args, **kw)
          File "neo/tests/threaded/test.py", line 2019, in testNotifyReplicated
            self.assertEqual([15, 11, 13, 16], [r[x].value for x in 'abcd'])
          File "neo/tests/__init__.py", line 187, in assertEqual
            return super(NeoTestBase, self).assertEqual(first, second, msg=msg)
        failureException: Lists differ: [15, 11, 13, 16] != [19, 11, 13, 16]
      
        First differing element 0:
        15
        19
      
        - [15, 11, 13, 16]
        ?   ^
      
        + [19, 11, 13, 16]
        ?   ^
      40bac312
    • Julien Muchembled's avatar
      6841e2f2