1. 26 Mar, 2019 1 commit
  2. 21 Mar, 2019 5 commits
  3. 20 Mar, 2019 13 commits
  4. 15 Mar, 2019 2 commits
  5. 13 Mar, 2019 1 commit
  6. 12 Mar, 2019 2 commits
  7. 11 Mar, 2019 3 commits
  8. 08 Mar, 2019 6 commits
    • Kirill Smelkov's avatar
      . · cd7fce8c
      Kirill Smelkov authored
    • Kirill Smelkov's avatar
      . · 8b0816bc
      Kirill Smelkov authored
    • Kirill Smelkov's avatar
      . · 424beee4
      Kirill Smelkov authored
    • Kirill Smelkov's avatar
      . · 501b7b27
      Kirill Smelkov authored
    • Kirill Smelkov's avatar
      X Don't keep ZBigFile activated during whole current transaction · 89ad3a79
      Kirill Smelkov authored
      If we keep it activated, there could be a problem at Resync time - if
      Resync sees that old zhead.At is outside of DB.δtail coverage it will
      invalidate all zhead.cache objects, not only changed objects. That means
      that even non-changed and being kept active ZBigFile will be invalidated
      and oops - PInvalidate will panic.
      We could avoid it via deactivating all ZBigFiles on each transaction
      update, but that can be too expensive if there are many ZBigFiles.
      We could avoid the problem another way - add to ZODB/go API to request
      that DB.δtail covers particular connection. That in turn would mean we
      have to also extend ZODB/go API to release connection from affecting DB
      via such constraint. Even if first step could be done via e.g. another
      flag, the second step - release - is not very clear - we already have
      connection "release" on transaction completion and adding e.g.
      conn.Close() in addition to that would be ambiguous for users.
      Also, if wcfs is slow to process invalidations for some reason,
      such constraint would mean DB.δtail would ↑ indefinitely.
      -> we can solve the problem in another way: don't keep ZBigFile always
      activated and just do activation/deactivation as if working with ZODB
      objects regularly. This does not add any complications to code flow and
      from the performance point of view we can practically avoid the slowdown
      by teaching zodbCacheControl to also pin ZBigFile in live cache.
    • Kirill Smelkov's avatar
      . · 5f7c757e
      Kirill Smelkov authored
  9. 07 Mar, 2019 1 commit
  10. 05 Mar, 2019 1 commit
  11. 04 Mar, 2019 2 commits
    • Kirill Smelkov's avatar
      X wcfs: Care to disable OS polling on us · 59552328
      Kirill Smelkov authored
      If we don't early-disable it, we can see a situation where when
      handling invalidations wcfs calls open("@revX/bigfile/...") to upload
      cache data there, go runtime tries to use epoll on that fd, and it gets
      stuck as described in the commit referenced in comments.
      In particular the deadlock was easy to trigger with nproc=1 environment
      (either a VM with 1 cpu, or e.g. under `taskset -c 0`)
      Bug reported by @romain.
    • Kirill Smelkov's avatar
      . · e8c3499d
      Kirill Smelkov authored
  12. 01 Mar, 2019 1 commit
  13. 25 Feb, 2019 1 commit
  14. 22 Feb, 2019 1 commit