1. 09 Apr, 2021 6 commits
  2. 05 Apr, 2021 3 commits
  3. 02 Apr, 2021 1 commit
  4. 01 Apr, 2021 10 commits
    • Kirill Smelkov's avatar
      Merge branch 'master' into t · 0448570a
      Kirill Smelkov authored
      * master:
        tests: Reset transaction synchronizers before every test run
      0448570a
    • Kirill Smelkov's avatar
      . · 96df97a0
      Kirill Smelkov authored
      96df97a0
    • Kirill Smelkov's avatar
      tests: Reset transaction synchronizers before every test run · fe369d32
      Kirill Smelkov authored
      Else, e.g. after a failing test, that closed its storage and DB, but not
      all Connections, another test, just by starting new transaction, would
      invoke synchronization on that unclosed connection, which will try to
      access closed storage and likely fail.
      
      Fixes e.g. https://nexedijs.erp5.net/#/test_result_module/20210401-31B27B3D/5
      
      Crash scenariou is the same as described in 5a5ed2c7 (tests: Force-close
      ZODB connections in teardown, that testing code forgot to explicitly
      close). Only now we try to isolate tests from each other not only for
      different modules, but also for tests inside the same module.
      fe369d32
    • Kirill Smelkov's avatar
      Merge branch 'master' into t · e2dc8651
      Kirill Smelkov authored
      * master:
        lib/zodb: Add tests for critical ZODB properties that Wendelin.core 2 will depend on
        *: tests: don't hang on exception in non-main thread
      e2dc8651
    • Kirill Smelkov's avatar
      lib/zodb: Add tests for critical ZODB properties that Wendelin.core 2 will depend on · c37a989d
      Kirill Smelkov authored
      The tests verify that there is no concurrency bugs around load,
      Connection.open and invalidations. See e.g.
      
      https://github.com/zopefoundation/ZODB/issues/290
      https://github.com/zopefoundation/ZEO/issues/155
      
      By including the tests into wendelin.core, we will have CI coverage for
      all supported storages (FileStorage, ZEO, NEO), and for all supported
      ZODB (currently ZODB4, ZODB4-wc2 and ZODB5).
      
      ZEO5 is know to currently fail zloadrace.
      However, even though ZODB#290 was fixed, ZEO5 turned out to also fail on zopenrace:
      
              def test_zodb_zopenrace():
                  # exercises ZODB.Connection + particular storage implementation
          >       zopenrace.main()
      
          lib/tests/test_zodb.py:382:
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
          <decorator-gen-1>:2: in main
              ???
          ../../tools/go/pygolang/golang/__init__.py:103: in _
              return f(*argv, **kw)
          lib/tests/testprog/zopenrace.py:115: in main
              test(zstor)
          <decorator-gen-2>:2: in test
              ???
          ../../tools/go/pygolang/golang/__init__.py:103: in _
              return f(*argv, **kw)
          lib/tests/testprog/zopenrace.py:201: in test
              wg.wait()
          golang/_sync.pyx:246: in golang._sync.PyWorkGroup.wait
              ???
          golang/_sync.pyx:226: in golang._sync.PyWorkGroup.go.pyrunf
              ???
          lib/tests/testprog/zopenrace.py:165: in T1
              t1()
          _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
      
              def t1():
                  transaction.begin()
                  zconn = db.open()
      
                  root = zconn.root()
                  obj1 = root['obj1']
                  obj2 = root['obj2']
      
                  # obj1 - reload it from zstor
                  # obj2 - get it from zconn cache
                  obj1._p_invalidate()
      
                  # both objects must have the same values
                  i1 = obj1.i
                  i2 = obj2.i
                  if i1 != i2:
          >           raise AssertionError("T1: obj1.i (%d)  !=  obj2.i (%d)" % (i1, i2))
          E           AssertionError: T1: obj1.i (3)  !=  obj2.i (2)
      
          lib/tests/testprog/zopenrace.py:156: AssertionError
      c37a989d
    • Kirill Smelkov's avatar
      . · c922735b
      Kirill Smelkov authored
      c922735b
    • Kirill Smelkov's avatar
      . · d9e13fbe
      Kirill Smelkov authored
      d9e13fbe
    • Kirill Smelkov's avatar
      . · 3fa4b406
      Kirill Smelkov authored
      3fa4b406
    • Kirill Smelkov's avatar
      . · bcc430c2
      Kirill Smelkov authored
      bcc430c2
    • Kirill Smelkov's avatar
      *: tests: don't hang on exception in non-main thread · 08e0c9fb
      Kirill Smelkov authored
      Previously if an assert or something failed in spawned thread, the main
      thread was usually spinning indefinitely = tests hang. -> Switch all
      threading places to use sync.WorkGroup and this way if a thread fails,
      all other threads are canceled and the exception is reported back to
      wg.wait in main thread.
      
      Since we start to go this route, NotifyChannel is reworked to fully use
      channels instead of busy-waiting.
      08e0c9fb
  5. 31 Mar, 2021 2 commits
  6. 30 Mar, 2021 3 commits
  7. 26 Mar, 2021 4 commits
  8. 22 Mar, 2021 1 commit
  9. 08 Mar, 2021 3 commits
    • Kirill Smelkov's avatar
      tox: v↑ NEO (1.9 -> 1.12) · 95b012d3
      Kirill Smelkov authored
      NEO 1.9 was released in 2018 and is outdated by now. NEO 1.12 is
      currently the latest NEO release.
      95b012d3
    • Kirill Smelkov's avatar
      Require Zodbtools · d62a297c
      Kirill Smelkov authored
      After switching to ZODB >= 4 in the previous commit, we can safely
      require zodbtools, because there is now no conflict in between
      ZODB3/ZODB eggs.
      d62a297c
    • Kirill Smelkov's avatar
      Drop support for ZODB3 · 0802da2b
      Kirill Smelkov authored
      It's been a while since last ZODB3 3.10.7 release in 2016 and the last
      commit in upstream ZODB3 repository (3.10 branch) is from 2017. The
      world switched since then to ZODB4 and to ZODB5 after that.
      
      We were still requiring ZODB3, because ZODB3 3.11 egg was just a
      dependency on newer ZODB, ZEO, BTrees and persistent; and this way we
      could be supporting all ZODB3.10.x and  ZODB4 and ZODB5 via ZODB3.11.
      
      However upcoming Wendelin.core 2, for its proper working, needs MVCC
      semantic as implemented in ZODB5. This forces us, even for ZODB4, to
      backport non-trivial bits from ZODB5 (see [1]). Maintaining ZODB3
      support at this point becomes non-practical, because, to our knowledge,
      there is no wendelin.core user that plans to continue using ZODB3
      without switching to at least ZODB4 in the near future.
      
      So goodbye ZODB3. Even though ZODB still stays with us, it gives a
      feeling similar to [2], because in 2014, when I was myself learning
      ZODB, it was through ZODB3 - still at the time when all ZODB bits were
      living together in one place.
      
      [1] ZODB!1
      [2] https://lists.osuosl.org/pipermail/darcs-users/2008-September/014095.html
      0802da2b
  10. 03 Mar, 2021 2 commits
  11. 02 Mar, 2021 2 commits
  12. 01 Mar, 2021 1 commit
  13. 03 Jan, 2021 1 commit
  14. 11 Dec, 2020 1 commit